search

shermp / NickelDBus

Monitor and control kobo Nickel via dbus
MIT License
24 stars 2 forks source link

Initial persistent dialog implementation #8

Closed shermp closed 3 years ago

shermp commented 3 years ago

Carmelocotonto on MR asked in post #22 the following:

Could I even make the message stick while the file.sh is running? (not only 4 seconds)? [this is in regards to the toast]

I thought such a feature would be neat to have, so I've cobbled something together using the confirmation dialog stuff.

This PR introduces two new methods that allows you to show a 'persistent' dialog box, which will show until the other method is called to close it, or the user dismisses the dialog. This could be a way of blocking user interaction while doing an Important Task(tm)

It's possible to create a dialog that the user cannot close at all, but I thought it's probably safer to give the user an out for misbehaving scripts/programs.

This is marked WIP still, because I'm not entirely sold on the method naming, or if I've even taken the correct approach. Feedback is most welcome.

NiLuJe commented 3 years ago

I'd possibly add a timeout, too ;).

(e.g., https://github.com/koreader/koreader/blob/master/frontend/ui/widget/infomessage.lua)

shermp commented 3 years ago

I'd possibly add a timeout, too ;).

(e.g., https://github.com/koreader/koreader/blob/master/frontend/ui/widget/infomessage.lua)

Then one may as well use a toast!

The point of this is to display the message at the beginning of a long running task, and dismiss it at the end of said task. You can't do that with a timeout.

shermp commented 3 years ago

And why not let the developer change the body text on an existing persistent dialog while we're at it 😁

shermp commented 3 years ago

I can't think of any more functionality I want to add to this particular feature, so I think it's ready for review.

shermp commented 3 years ago

Belay that. I think I've just had a better idea on how to do this.

shermp commented 3 years ago

Alright, I've rolled back the use of separate dialog 'types' in favor of just extending the new functionality of the existing confirmation dialog handling.

The upshot of this is that the new 'change' and 'close' methods can now apply to the existing dialog options, as well as the new 'modal, message only' style.

Also, means less code duplication, so yay!

shermp commented 3 years ago

@NiLuJe , @pgaskin after yesterdays false start, I think this is done now. (Hopefully I don't get any more bright ideas when I go make lunch)