<div dir="auto"><br>
<br>
On Thu, Aug 1, 2019 at 10:30 AM Konrad Materka <<a href="mailto:materka@gmail.com" target="_blank" rel="noreferrer">materka@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> recently I was fixing two bugs related to SystemTray (in review:<br>
> <a href="https://phabricator.kde.org/D22804" rel="noreferrer noreferrer" target="_blank">https://phabricator.kde.org/D22804</a>,<br>
> <a href="https://phabricator.kde.org/D22767" rel="noreferrer noreferrer" target="_blank">https://phabricator.kde.org/D22767</a>). I noticed that code is highly<br>
> coupled and "fragile" with some unclear references like:<br>
> item.parent.parent.attrbute etc. Items are imperatively assigned to<br>
> different parents depending on the status.<br>
<br>
Firstly, thanks ever so much for looking into the xembedsniproxy code!<br>
It's good to have someone active on it.<br>
<br>
(note that I have a super minor review comment on one, then let's ship it ASAP)<br>
<br>
><br>
> I would like to add one meta-model with all items (both<br>
> SystemNotifications and plasmoids) plus Delegate Model(s) with groups:<br>
> * active<br>
> * passive/hidden<br>
> * disabled etc<br>
> and additional sorting:<br>
> * notification always as first<br>
> * other rules possible<br>
<br>
Seems sane. <div dir="auto"><br></div><div dir="auto">If you use actual models, see KExtraRowsProxyModel for merging.<br>
<br>
><br>
> That model will allow:<br>
> * better separation between data and view, it is additional abstract<br>
> layer between backend data (SystemNotifications model + plasmoids<br>
> list) and current view.<br>
> * ability to filter/sort/group easily - no need for<br>
> plasmoid.nativeInterface.reorderItemAfter<br>
> * clear information about the model used in active/hidden containers<br>
> * easier implementation of new features like ordering, even with drag<br>
> and drop  (<a href="https://bugs.kde.org/show_bug.cgi?id=384782" rel="noreferrer noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=384782</a>)<br>
> * decoupled code (with further refactoring, preferably not in one step)<br>
> no direct parent assignment.<br>
><br>
> The biggest disadvantage (?) I see is that it adds some complexity,<br>
> change is big and will require quite long review process.<br>
> I predict it will take around 4 weeks + 4 weeks (or more) for reviews/fixes.<br>
><br>
> What do you think? Should I start work or someone else is working on SystemTray?<div dir="auto"><br></div><div dir="auto">Go for it. You might find it useful to review Marco's new containment management plugin for the desktop. It has a controls like approach for creating loaders. </div><div dir="auto"><br></div><div dir="auto">There should be some crossover which might be relevant.</div><div dir="auto"><br>
> --<br>
> Regards,<br>
> Konrad Materka<br></div></div></div>