| davidedmundson |
| Frameworks |
Currently we have a 5 minutes timeout duration.
I would say any application that does not respond in 5 seconds is buggy, or at least in a bad state.
This timeout can hide bugs because this code will block the current thread.
The user won't have any feedback before the timeout expires.
Encountered this issue while testing krunner.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 20071 | |
| Build 20089: arc lint + arc unit |
I'd say 5 seconds is optimistic.
Does Kate's session selection dialog still block startup?
Granted.
10 seconds maybe.
Does Kate's session selection dialog still block startup?
I am not aware of this.
I would say any application that does not respond in 5 seconds is buggy, or at least in a bad state.
That's not necessarily true. We're asking an app to quit, it could be showing prompts to the user.
It doesn't necessarily imply it's frozen or anything.
Encountered this issue while testing krunner.
Can you expand on this, so I can see what problem we're actually trying to solve.
I had a "org.kde.krunner" service registered in dbus session but no application behind it, making the next run of krunner hang for 5 minutes.
I wanted to have a faster feedback, instead of having to gdb into krunner.
I wonder how can a a service still be registered in dbus while its program has finished.
I had to close my session to solve this issue.