[System Tray]

[Konrad Materka]

pon., 5 sie 2019 o 06:55 David Edmundson <david at davidedmundson.co.uk>
napisał(a):
> On Thu, Aug 1, 2019 at 10:30 AM Konrad Materka <materka at gmail.com> wrote:
> >
> > Hi,
> >
> > recently I was fixing two bugs related to SystemTray (in review:
> > https://phabricator.kde.org/D22804,
> > https://phabricator.kde.org/D22767). I noticed that code is highly
> > coupled and "fragile" with some unclear references like:
> > item.parent.parent.attrbute etc. Items are imperatively assigned to
> > different parents depending on the status.
>
> Firstly, thanks ever so much for looking into the xembedsniproxy code!
> It's good to have someone active on it.
>
> (note that I have a super minor review comment on one, then let's ship it ASAP)

Sorry, my bad, I didn't noticed that comment must be submitted -
embarrassing :) Please check now.

> > I would like to add one meta-model with all items (both
> > SystemNotifications and plasmoids) plus Delegate Model(s) with groups:
> > * active
> > * passive/hidden
> > * disabled etc
> > and additional sorting:
> > * notification always as first
> > * other rules possible
>
> Seems sane.
>
> If you use actual models, see KExtraRowsProxyModel for merging.

Did you mean KConcatenateRowsProxyModel? OK, will check that. I was
also thinking about pure QML model, I need to experiment with few
ideas.
There is one model (data source) for SystemNotifications, plasmoids
are already created as graphical items so these two does not mix well.

> > That model will allow:
> > * better separation between data and view, it is additional abstract
> > layer between backend data (SystemNotifications model + plasmoids
> > list) and current view.
> > * ability to filter/sort/group easily - no need for
> > plasmoid.nativeInterface.reorderItemAfter
> > * clear information about the model used in active/hidden containers
> > * easier implementation of new features like ordering, even with drag
> > and drop  (https://bugs.kde.org/show_bug.cgi?id=384782)
> > * decoupled code (with further refactoring, preferably not in one step)
> > no direct parent assignment.
> >
> > The biggest disadvantage (?) I see is that it adds some complexity,
> > change is big and will require quite long review process.
> > I predict it will take around 4 weeks + 4 weeks (or more) for reviews/fixes.
> >
> > What do you think? Should I start work or someone else is working on SystemTray?
>
> 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.
>
> There should be some crossover which might be relevant.

Are you referring to: https://phabricator.kde.org/D22034 ? For now I
will try not to change anything on the presentation layer to avoid
regressions. Next step would be to change layout, maybe similar to
https://phabricator.kde.org/D19745 (which was reverted due to
regressions).

> > --
> > Regards,
> > Konrad Materka