| Summary: | script added to autostart cannot be configured to run at shutdown | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Peter Gantner <nephros> |
| Component: | kcm_autostart | Assignee: | Laurent Montel <montel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | brunomcl, kde, michael, mikiya.okuno, s_chriscollins |
| Priority: | NOR | Keywords: | investigated |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kde-workspace/044c91d6f6adf3e3d935c652c659f5346c6c2011 | Version Fixed In: | 4.9.4 |
| Sentry Crash Report: | |||
|
Description
Peter Gantner
2010-02-27 19:21:12 UTC
for got one thing: If I later move the symlink from ~/.kde4/Autostart to ~/.kde4/shutdown, the Autostart settings shows it correctly configured to run on shutdown. I'd like to confirm this bug in KDE 4.6.3 "release 4", exactly as the OP described. I can confirm this bug exists in KDE 4.6.4 as well. Additionally, setting a script to run on shutdown will often move the wrong script to the shutdown folder! I figured out what is happening: 1) When a script is set to "Startup", it is to be placed in ~/.kde/Autostart. When a script is set to "Shutdown", it is to be placed in ~/.kde/shutdown. 2) When you select one of these options, the KDE autostart module is moving the script that is currently highlighted (blue by default) regardless of which script's combo box you have just accessed. So, the current workaround is to click on the script's entry so it is highlighted in blue, then select its startup option from the combo box. BTW: I didn't test with the "Pre-KDE Startup" option, but I'd assume it's the same story there. I face the same problem too.
I figure out the problem. This happens when there are more than one items under the "Script File". Every time when manipulate an item which does not has the focus, the focused item is moved! So item selection is wrong.
void Autostart::slotChangeStartup( int index )
{
if ( widget->listCMD->currentItem() == 0 )
return;
ScriptStartItem* entry = dynamic_cast<ScriptStartItem*>( widget->listCMD->currentItem() );
if ( entry )
{
entry->setPath(m_paths.value(index));
if ( ( index != 0 ) && !entry->fileName().path().endsWith( ".sh" ))
KMessageBox::information( this, i18n( "Only files with “.sh” extensions are allowed for setting up the environment." ) );
}
}
QListWidget::currentItem() does not return the item which is manipulated, but returns the item which has the focus. I don't know what is the correct logic to select the item though.
Cheers!
Thanks for the helpful steps and investigation. I will see whether I can do something to fix this :) Git commit 044c91d6f6adf3e3d935c652c659f5346c6c2011 by Jekyll Wu. Committed on 10/11/2012 at 05:40. Pushed by jekyllwu into branch 'KDE/4.9'. Make sure the right item is operated on when changing startup type The problem was the "current" item was sometime not the one you would have expected when changing the startup type of item A: * it could be "none" * it could be the previous "current" item The fix is a little hacky, but better than none. FIXED-IN: 4.9.4 M +8 -7 kcontrol/autostart/autostart.cpp M +1 -1 kcontrol/autostart/autostart.h M +8 -1 kcontrol/autostart/autostartitem.cpp M +11 -1 kcontrol/autostart/autostartitem.h http://commits.kde.org/kde-workspace/044c91d6f6adf3e3d935c652c659f5346c6c2011 *** Bug 171139 has been marked as a duplicate of this bug. *** Thanks for the fix, Jekyll! Jekyll, Thank you for the fix! The fix looks reasonable. *** Bug 310629 has been marked as a duplicate of this bug. *** |