adept does not show wanted user input

Bug #37696 reported by Asraniel
82
Affects Status Importance Assigned to Milestone
ept (Ubuntu)
Fix Released
Medium
mornfall

Bug Description

if i try to install flash-nonfree with adept, after the downloading, at installation, adept suddenly stops. it stays at 0%. i just discovered that i have to click on view details to see that the flash installation wants me to confirm a few things.
i think in breezy this bug was not present.

Revision history for this message
Asraniel (asraniel) wrote :

and it happend again after the last update of the flash plugin. very confusing for the user that adept stops working and he has to click on see details to accept a dialog.

Changed in ept:
status: Unconfirmed → Confirmed
mornfall (mornfall)
Changed in adept:
assignee: nobody → me-mornfall
Revision history for this message
Krzysztof Lichota (krzysiek-launchpad-ubuntu-com) wrote :

I think it should be possible to use "Detect silence" feature of embedded Konsole to catch such situation and in such case expand "Details" tab and attract user attention by flashing taskbar entry.

Revision history for this message
mornfall (mornfall) wrote :

I have had same idea (detect silence), but the problem is that i can't access the konsole API, since it's private. That basically either means having a private copy of konsole again (which blows) or patching kdelibs+kdebase and waiting for upstream picking this up. I think i have also tried to see if there is a dcop interface to no avail. If you know something i don't in this matter, please let me know, i would love to solve this...

Revision history for this message
Edu (martinez-bernal) wrote :

Hi,
I suggest in the meanwhile, maybe details can be the default view

Revision history for this message
Brice Arnould (un-brice) wrote :

Maybe I'll say something stupid, but if I record well, there's a way to tell debconf to use a Qt interface with somethinglike "dpkg-reconfigure debconf".
That would be more user friendly, and would work around the problem.

Revision history for this message
Krzysztof Lichota (krzysiek-launchpad-ubuntu-com) wrote :

> I have had same idea (detect silence), but the problem is
> that i can't access the konsole API, since it's private.

I didn't know that. I guess in such case it is best to push the change into Ubuntu-specific kde patches and later push it upstream.

Revision history for this message
Krzysztof Lichota (krzysiek-launchpad-ubuntu-com) wrote :

BTW. Feature freeze for KDE has been lifted after KDE 3.5.3, so it might be good moment to push this change for KDE 3.5.4.

Revision history for this message
Robert Knight (robertknight) wrote :

> waiting for upstream picking this up

Hello, I am the current maintainer of Konsole. I'm quite happy to commit the patches for this, but you do have to make sure that I am aware of the problem. I didn't know anything about it until I came across the bug report today.

The best ways to get the attention of myself and other developers are:

- Email the konsole mailing list (<email address hidden>)
- Email the current maintainer (email address found in the "Help -> About Konsole" dialog in Konsole itself)

Or you can email the more general kde-devel mailing list.

I do look over bug reports from time to time, but looking over all 145 bug reports, much less addressing any of them, takes time. Plus the bug reports do not usually give enough context information to indicate the severity of the bug for the user affected. "Please add a dcop command to enable feature X" doesn't tell me that it is a serious issue for Kubuntu users because it basically means they cannot install some important software using the supplied graphical tool.

Aside from that, I really have to ask if there is any other way of knowing that questions will be asked and allowing the user to respond. Waiting for silence using the terminal's "detect silence" feature seems very ugly. If the silence timeout is too short then the terminal will keep opening up. If it is too long then people will end up waiting for ages wondering why the system is taking so long.

Revision history for this message
Marco Cimmino (cimmo) wrote :

I think ept is wrong package, now there is adept isn't?

Revision history for this message
Krzysztof Lichota (krzysiek-launchpad-ubuntu-com) wrote :

Robert, do you have any other way of detecting that process is waiting for user input apart from watching for silence? dpkg frontend is using curses interface, maybe hooking into it would help?

If that's not the case, I guess waiting for silence for, let's say 1 minute, indicates that process is not doing anything and waiting for action. Adept would need the way to:
1. Turn on monitoring for silence in Konsole, with specified timeout (probably using DCOP).
2. Get notification about silence detection from embedded Konsole. I am not sure how this could be done. Maybe Konsole could just raise the application in which it is embedded?

Revision history for this message
Brice Arnould (un-brice) wrote :

Just a naive thought : why not to use the Qt interface (as activated by "dpkg-reconfigure debconf" or "--frontend=") instead of the ncurse one ?

Revision history for this message
DaveQB (david-dward) wrote :

Maybe also hook into CPU usage, being that installing a package(s) often peaks the CPU.

Just a thought.

Revision history for this message
Yuriy Kozlov (yuriy-kozlov) wrote :

This is fixed in Feisty, and likely to be backported to Edgy.

Changed in ept:
status: Confirmed → Fix Released
Revision history for this message
Krzysztof Lichota (krzysiek-launchpad-ubuntu-com) wrote :

What about backporting to Dapper, which is long-term release?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.