- User Since
- Jul 26 2019, 6:30 PM (7 w, 6 d)
Tue, Sep 17
Sorry for interrupting this late in the review. I like the idea of consistent ordering very much, I even planned to implement this myself :) I have few comments:
Due to a bug in Repeater it is needed sometimes. Repeater randomly changes the parent item after it was created and re-parented (race condition?). I had big troubles with Repeater, especially combining with Loader, DelegateModel.Package etc. Repeater is very buggy, in other words, it works by happy coincidence. :)
Tue, Aug 27
Mon, Aug 26
Now the same model is used for:
- rendering all items, both Plasmoids and StatusNotifications
- "Entries" configuration page
Sat, Aug 24
@nicolasfella Please correct me if I'm wrong. EntryModel is created on the first use and it is populated in the constructor. If user runs application that uses StatusNotifier (for example Skype, Dropbox, Electron apps, any Windows app via Wine, etc) later, it won't be added to configuration list.
I spent some time testing it and I hope it is now bug free. I understand it is a big change that brings little value (now), but I'm working on further improvements and wanted to slip work into smaller patches.
Aug 6 2019
Aug 5 2019
Jul 29 2019
I simplified the patch. It moves handling of onPressed to PlasmoidItem. This way we can have context menu when mouse is pressed for plasmoids and on click for SNI.
Should this be done together with this change? I shouldn't be hard, I can move onPressed to PlasmoidItem, which will simplify the fix also?
@apol SNI applications (including XembedSniProxy) are using StatusNotifierItem.qml, which already has onClick handled for right button. That why we had ContextMenu event's duplicated.
@broulik Yes, probably onPressed should be handled in PasmoidItem, not in the AbstractItem to avoid this kind of problems. I would personally opt for consistency, though. As far as I know GTK is showing context menu on mouse click, not pressed. The same is for MS Windows (this does not mean we must follow this or reimplement Windows, no). What is your opinion?
Review changes. Call to the calculateClickPoint is local and on only on mouse click, not on every icon update.