It's also may be possible to repeat unmount request from solid a few times with some delays between requests to try waiting until preview jobs are stopped when unmount is requested from 'mounted devices' widget. I've tried 5 retries with 2 seconds between each one, and it worked for me. But waiting for replies to unmount notifications in solid might be preferable to retries.
Thu, Mar 26
Leave out kdsoap-ws-discovery-client, it's maintained somewhere else...
Looks good to me, not that this means much with regular expressions. The lack of tests on this stuff makes me sad :((
Wed, Mar 25
Demo of feature:
Done! Nice job.
It makes me think we should improve PreviewJob to be devicePixelRatio aware, so we can fix the tooltips too.
It seems that everyone accepted this, could you help me to land this to whatever branch you want ?
I've actually had a better idea! Well kinda and it may be trickier to do.
Tue, Mar 24
@elvisangelaccio is it okay to depend on frameworks master or should I wait for the frameworks release before merging this?
Thanks, but you need to update the diff using arc rather than providing a link to a new patch file.
Looks ok now.
@ngraham @meven : here is a new patch: https://www.shlomifish.org/Files/files/code/dolphin--shlomif-patch-D26362--modified-v0.2.0.patch but note that it makes no difference and om fedora 32 x64 it seems that pressing enter twice invokes the top item in the results which was already selected. It also can be done as "down arrow; enter" using either of my patches.
@ngraham : hi! I am interested in finishing it up, but will be fine with someone else doing that. I'll try to get to it soon.
Massage a string
@shlomif are you interested in finishing up this patch?
Ok to me @bruns ?
I agree. And this behavior should be also implemented for the Return case which is lacking this at the moment.
A requestFocusAndSelectFirstItem for instance.
Mon, Mar 23
Seems fine to me, adding @pino who could give more insights.
I thought that it was important to put all the components of a final string together in the i18n() function to prevent string puzzles. If that's not a concern here, I can remove the path from the translated part of the string.
Is there a reason to include the path in the translated string? Not including it would reduce the risk of translations breaking the feature (as it happens currently with Spanish in the extension case)
This involves a string change, but given that it's to fix a bug with the feature not working correctly, I'd like to request a a string change exception from the Localization team.
Seems fine to me
Yeah due to the quantity of new code, it feels more like 20.08 material, TBH.
Any opinions on landing this for 20.04 still? It is technically a bugfix. It is also practically a whole lot of risky code, making me rather uneasy about putting it in past beta.
Sat, Mar 21
I'm not really sure about the icon on the left of the URL when it's inside the toolbar, but otherwise this looks great visually on first impressions.
Fri, Mar 20
(Also could some one with more power than me clang-format this whole repo (there's a clang-format.cmake in extra-cmake-modules)? just note that some hand-formatted char* definitions blow up :)).
Looks good to me.
Thu, Mar 19