| 2006-05-25 15:29:29 |
Ian Jackson |
bug |
|
|
added bug |
| 2006-10-05 11:45:21 |
Colin Watson |
ubiquity: status |
Unconfirmed |
Confirmed |
|
| 2006-10-05 11:45:21 |
Colin Watson |
ubiquity: statusexplanation |
|
I tried to fix this by (a) setting the "default" property on the next button in the .ui file and, separately, (b) putting self.userinterface.next.setDefault(True) after everything that programmatically enables the next button. Neither worked: the next button was the default for the first step, but after that the default became the cancel button. This is presumably due to the way we disable the next button temporarily, but I can't think of any other ways to force it to be the default again after re-enabling it.
Jonathan, can you help at all here? |
|
| 2008-11-30 17:23:19 |
Adam Niedling |
ubiquity: status |
Confirmed |
Invalid |
|
| 2008-11-30 17:23:19 |
Adam Niedling |
ubiquity: statusexplanation |
I tried to fix this by (a) setting the "default" property on the next button in the .ui file and, separately, (b) putting self.userinterface.next.setDefault(True) after everything that programmatically enables the next button. Neither worked: the next button was the default for the first step, but after that the default became the cancel button. This is presumably due to the way we disable the next button temporarily, but I can't think of any other ways to force it to be the default again after re-enabling it.
Jonathan, can you help at all here? |
Was this still an issue in the final version of Dapper(?) ? |
|
| 2008-12-21 12:20:42 |
Colin Watson |
ubiquity: status |
Invalid |
Triaged |
|
| 2008-12-21 12:20:42 |
Colin Watson |
ubiquity: statusexplanation |
Was this still an issue in the final version of Dapper(?) ? |
This is still a valid and important issue. You had no justification for closing it. |
|
| 2009-09-17 18:43:48 |
Adam Niedling |
removed subscriber Adam Niedling |
|
|
|
| 2012-02-25 01:03:16 |
Rich Johnson |
ubiquity (Ubuntu): status |
Triaged |
Fix Released |
|
