-
Notifications
You must be signed in to change notification settings - Fork 23
Show list of things to be restarted on the "Restart Services" dialog #136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Again @b100dian please check my CPP, I'm sure it's horrible. |
I actually find Qt to be very powerful for not tripping on horrible C++ things and is really nicely used by you:) I'll look in depth ~tomorrow I need to ramp up on dbus types, but recently I found that |
I came up with it more or less trial-and-error, and IIRC I got compilation errors when trying 'as'. It's possible something else was the root cause for those though. |
src/qml/patchmanager.cpp
Outdated
| }); | ||
|
|
||
| QDBusPendingCallWatcher *watchGetToggleServicesList = new QDBusPendingCallWatcher(m_interface->getToggleServicesList(), this); | ||
| connect(watchGetToggleServicesList, &QDBusPendingCallWatcher::finished, [this](QDBusPendingCallWatcher *watcher){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get no clue from the documentation that this fires any more than once.
I think it is also true that patch updates are notified only when entering the PM settings page and the Restart Services is finicky in the sense that it doesn't show if you first open the menu. I am not 100% sure as I haven't debugged this.
For example, I had to close and re-open the Settings app to get more than one item in the RestartServicesDialog Repeater.
So I guess the call for watcher can be moved to the getter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this call is useful in the qml page, so it could be made synchronous with no devastating consequences.
The repeated query needs to be done for the boolean that makes the menu entry appear.
Btw, thanks, I did not know what Restart services did until today!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get no clue from the documentation that this fires any more than once.
Hmm, that's suboptimal ;)
I think it is also true that patch updates are notified only when entering the PM settings page and the Restart Services is finicky in the sense that it doesn't show if you first open the menu. I am not 100% sure as I haven't debugged this.
For example, I had to close and re-open the Settings app to get more than one item in the RestartServicesDialog Repeater.
The easiest way to get it to appear is to unapply and re-apply a patch (or preferrably, more than one from different categories).
So I guess the call for watcher can be moved to the getter?
I'll play around with that and see how it goes. THanks for the thorough testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is exactly what I was suggesting - a plain synchronous getter. I am not sure about "seems to work" - did you also see problems with the one-off triggered callback from the original version (and existing pattern)?
(While I usually do prefer asynchronous calls, this may not be one of the cases to sweat on).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is exactly what I was suggesting - a plain synchronous getter. I am not sure about "seems to work" - did you also see problems with the one-off triggered callback from the original version (and existing pattern)?
Not really. One thing I'm not sure about is Signals. Do we need one, when to fire it, when/how it is used form QML when constructing/reading the model etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that since the model is not changed without QML calling the getter we won't need the toggleServicesListChanged and QML will only call the getter once when the dialog is shown up (or: every time).
So basically if the appsNeedRestart is working correctly for the menu to appear, the getter will too.
(I still don't have an explanation why appsNeedRestart works more than once though. Maybe it so happens that it is only set from false to true only once and from there the getToggleServices is called when you navigate to the page)
| Repeater { | ||
| model: PatchManager.appsToRestart | ||
| delegate: Component { TextSwitch { | ||
| text: qsTranslate("Sections", modelData) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works for all languages but English, because English doesn't have a dedicated translation and so uses the (lowercase) original strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that a serious issue from your POV? I.e., serious enough to resurrect and maintain the English TS file?
My first thought was: So what, then it just uses lower case strings.
Or maybe this dialog (its textual context) can phrased in a way, that this is fine without having these strings starting with a capital letter?
But as you seem to have looked at it in "real life", just decide how to proceed.
Resolved per #153
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, totally minor issue that just came up along the way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to document that Transifex uses "translated" strings from the source file as source strings, when the are available (which makes sense IMO).
Side note: Thus this change changed the source strings of all 14 PM-categories for all 14 translations. And because Transifex does not allow programmatic changes at Transifex (e.g., per RegEx), I manually adapted these 14 terms for 13 translations (all, but zh). Maybe scripted downloading, programmatic changing the strings locally and scripted uploading would have been easier, but that would have required learning how to use Transifex's web API, which I wanted to avid this time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nephros, please use the exclamation mark only if something went wrong.
Unfortunately the classic conventions for writing dialogues are less obeyed than in the early 2000s, but I still would like to stick to them.
- ! means: Attention, something went wrong.
- ... (concluding, i.e., at the end of a phrase or sentence) means: A new window is going to be opened. This is most suitable for choices (which would open a new window).
- There are more, which I do not remember spontaneously.
The dialogues in MS-Windows and most of KDE and Gnome are adhering to these conventions, so people are used to them (even most not consciously).
|
Just re-tested this and it works nicely |
Olf0
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking fine.
|
So, would you like this in now, or do we wait until after 3.2? @Olf0 as you have taken the mantle of release manager for the next couple of versions, please feel free to hit that green button whenever you think its appropriate. |
Huh, have I?
Well, this has become surprisingly big by accumulating a lot of fix-ups, but is clearly disjunct (technically and by functionality) from the principal, major feature for the next release: "32 / 64 bit" per #71 and #109 (comment) (which still has two checkboxes unchecked). Hence I will happily merge this now. |
"Inspired by" Issue-23