Add Autostart KCM to kdebase/workspace/kcontrol

Aaron J. Seigo aseigo at kde.org
Mon Feb 19 18:17:19 GMT 2007


On February 18, 2007, Stephen Leaf wrote:
> I've finished my port to kde4
> So first I'd like to ask is the above location Ok?
> Or should this be in a different section?

it should go into kdereview first for .. well, review =)

> Also does anyone have a name suggestion? I'm horrible with names and I'm
> told that autostart already exists and does about the same thing.

it does?

> And finally could I get a review of my code, suggestions, comments,
> questions, concerns?

a description of what it does and a url to a screenshot or two (so the 
usability folks who often don't have access to current trunk/ can look at it 
as well) would be helpful ... 

you don't need to include a copy of the GPL or installation instructions if it 
goes into a main module. the doxyfile can go to if i'm not mistaken.

i'm not sure the term "ENV" will mean much to anyone. a more user friendly 
string would be good there. essentially the difference between env/ and 
autostart/ is that env is pre-desktop loading and are actual scripts, whereas 
autostart/ is during desktop load and are .desktop files, correct? perhaps 
the name could reflect that difference.

the UI is hand-coded; using designer is the preferred mechanism.

why do you create your own local kstandarddirs in autostart::load()? you 
should be using componentData().dirs() no?

the for loop is a bit interesting as well =) wouldn't it be a bit cleaner to 
just do sth like:

QStringList paths;
paths << KGlobalSettings::autostartPath()
         << ksd->localkdedir() + "/shutdown" 
         << ksd->localkdedir() + "/env"; 

foreach (const QString& path, paths) {
    // do the loading
}

adding paths then becomes a matter of a new entry in the stringlist. or you 
could put the loading code in a method that takes the path as a parameter and 
call it three times =) *shrug* just looks a bit odd as it is...

more importantly though, while env/ works this way, autostart/ uses the 
cascading config system. so autostart items in $PREFIX can be overridden in 
$KDEHOME, for instance. it would be nice to list all those items, really, 
both so users can turn off global autostarts as well as not accidently 
override them with something of the same name.

so perhaps adding autostart and shutdown entries to the resource dirs in the 
kstandardirs object and using findAllResources would be more accurate? env/ 
would still need to be loaded as you are doing ... 

0.02 =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070219/3c101730/attachment.sig>


More information about the kde-core-devel mailing list