[kde] Re: Autostart locations in KDE4
Tim Edwards posted on Sat, 04 Jun 2011 14:26:24 +0200 as excerpted: > On Fri, 03 Jun 2011 15:29 +, "Duncan" <1i5t5.dun...@cox.net> wrote: >> Tim Edwards posted on Fri, 03 Jun 2011 14:05:32 +0200 as excerpted: >> Sure they can be reenabled. Simply start them manually, hit the >> krunner or kickoff hotkey and type into the box klipper. From the >> kickoff search box, it shows up after three letters. > > No, sorry but you're wrong about this. If you were right I would never > have needed to search around on how to make KNetworkManager startup > automatically. To prove it do a simple experiment: > 1. Click on klipper icon and choose 'quit' > 2. When it asks tell it not to automatically start > 3. Logout, log back in and verify klipper didn't start. > 4. Start klipper from the menu or krunner or wherever - it runs normally > 5. Logout and log back in - no klipper > > The point is that there is *no way* to re-enable these programs *except* > editing the klipperrc or networkmanagerrc and setting autostart=true. > Once you've closed them once they never start up automatically again > from the normal user's perspective. That's incorrect. When you told klipper not to start automatically at boot, it obeyed. You then started it again, logged out and back in, and it didn't start automatically, still obeying what you told it. To get it to start automatically again, you do the same thing you did to get it NOT to start automatically, but choose the other option. IOW, you start klipper, quit it manually so you get the quit dialog again, and... SURPRISE... tell it that you want it to start at login, again. It should now do so, and you haven't edited the rc file manually in ordered to do it. >> But that's my point. The user has the ability to add the entries to >> autostart if they want to (and if they're already running there's >> already a UI available to disable them), entirely separate from the way >> kde normally manages the system default entries. And that's the way it >> should be. The two setups should remain separate, so a user is always >> clear on the entries he's added himself, vs those managed by the >> system. > > Again, look at the file location - ~/.kde4/share/config/rc > - it *is* a user setting. If I set autostart=true or false in my > klipperrc, or close klipper and tell it not to restart (which is the > same as setting autostart=false) it is entirely separate from the way > KDE manages system default entries. I'm saying that this functionality, > the setting of autostart= in the user's own rc files, should be exposed > in the GUI. There are already 2 separate sections in Autostart - > .desktop files and scripts - there's no reason to not have a 3rd - > 'default programs' or something with just an enable and disable option > for each. It's a user setting, but a user setting for a normal part of the kde desktop. What I'm saying is that the autostart is for programs, kde or otherwise, that a user sets to run totally independent of the the normal kde desktop infrastructure. IOW, pan is an gtk not kde app. As such, there's no way to tell kde to start it as part of the kde desktop. xset is an command-line friendly app that controls X settings. It too is not part of the normal kde desktop. konsole is a part of the kde base platform, but its not part of the normally running kde background infrastructure, you normally start it directly. In any of these cases, autostart can be used to start the app automatically, but the user specifically sets up kde to do so on his own, totally independent of the default kde system settings. Actually, I have klipper manually added to autostart exactly the same way. It starts klipper, normally part of the kde background desktop functionality, but it does so entirely separately FROM that normal background functionality. The autostart functionality as covered by that kcontrol module is entirely separate from kde's normal "launches as part of kde" functionality, with entries that show up there indicating a direct action of the user to make it so, as opposed to the stuff kde normally does on its own because it's a part of the kde desktop experience. I'm saying that the two mechanisms are separate, and should remain so. Having one appear in the other would only confuse the fact that it's a separate mechanism. (However, see below for a change in my former position as described here.) > Your suggested way of manually adding them back is a workaround, not a > fix. It requires users to be able to find the name of the binary - > klipper or knetworkmanager or whatever. Plus users have to know in the > first place that to get these programs back they have to manually add > them. This is totally non-intuitive and for most users will require > them to ask on mailing lists and forums. As I explained in the earlier reply, no, users do NOT have to know the name of the binary. Simply typing something about the functionality, in the kli
[kde] Re: Autostart locations in KDE4
On Fri, 03 Jun 2011 15:29 +, "Duncan" <1i5t5.dun...@cox.net> wrote: > Tim Edwards posted on Fri, 03 Jun 2011 14:05:32 +0200 as excerpted: > Sure they can be reenabled. Simply start them manually, hit the krunner > or kickoff hotkey and type into the box klipper. From the kickoff search > box, it shows up after three letters. No, sorry but you're wrong about this. If you were right I would never have needed to search around on how to make KNetworkManager startup automatically. To prove it do a simple experiment: 1. Click on klipper icon and choose 'quit' 2. When it asks tell it not to automatically start 3. Logout, log back in and verify klipper didn't start. 4. Start klipper from the menu or krunner or wherever - it runs normally 5. Logout and log back in - no klipper The point is that there is *no way* to re-enable these programs *except* editing the klipperrc or networkmanagerrc and setting autostart=true. Once you've closed them once they never start up automatically again from the normal user's perspective. > > But that's my point. The user has the ability to add the entries to > autostart if they want to (and if they're already running there's already > a UI available to disable them), entirely separate from the way kde > normally manages the system default entries. And that's the way it > should > be. The two setups should remain separate, so a user is always clear on > the entries he's added himself, vs those managed by the system. Again, look at the file location - ~/.kde4/share/config/rc - it *is* a user setting. If I set autostart=true or false in my klipperrc, or close klipper and tell it not to restart (which is the same as setting autostart=false) it is entirely separate from the way KDE manages system default entries. I'm saying that this functionality, the setting of autostart= in the user's own rc files, should be exposed in the GUI. There are already 2 separate sections in Autostart - .desktop files and scripts - there's no reason to not have a 3rd - 'default programs' or something with just an enable and disable option for each. Your suggested way of manually adding them back is a workaround, not a fix. It requires users to be able to find the name of the binary - klipper or knetworkmanager or whatever. Plus users have to know in the first place that to get these programs back they have to manually add them. This is totally non-intuitive and for most users will require them to ask on mailing lists and forums. The basic principle is if the programs appear by default on a fresh home directory and can be disabled easily in the GUI they should be able to be re-enabled easily in the GUI. Tim ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards posted on Fri, 03 Jun 2011 14:05:32 +0200 as excerpted: > Your forgetting the problem that caused me to start this thread > originally: When you disable one of these programs from starting with > KDE by right-clicking on it and clicking 'quit' there is no way to > re-enable them. There is no way to even see what's disabled or enabled - > it just dissapears into the ether from the user's POV, like my > KNetworkManager. The only way is if the user searches on mailing lists > and forums and discovers that the 'clipboard thing' in their task bar is > called kclipper or something and they have to edit a some config file. Sure they can be reenabled. Simply start them manually, hit the krunner or kickoff hotkey and type into the box klipper. From the kickoff search box, it shows up after three letters. And those who don't remember what the thing that they just shut down was titled in ordered to type it in can find it easy enough browsing the kickoff menu. I didn't know where it was on the menu here but found it pretty fast, because the only possible categories that made sense were office (no, it's not there) and utilities. Or, if that's too much, simply knowing that it's a clipboard tool (how many people, even those still wet behind the ears from MS, don't know what the computer clipboard is, or at least don't know and yet would still be both inquisitive enough to have stumbled into accidentally shut the thing off in the first place and perhaps more importantly, know enough about what their missing to actually miss it -- if they even know enough to miss it they should know at LEAST enough to associate "clipboard" with it!) and typing clip into krunner... again comes up with klipper as an option. The other apps should be similar. If you were talking about an app without a menu entry it'd be one thing, but then, that'd be the bug, the missing menu entry. > Well maybe these things that are defined in /usr/share/autostart should > appear as services in the Startup & Shutdown module, but they don't. Actually, I wasn't aware that's where they were, but it's logical now that I know, and I'm reasonably confident I could have found them if needed. (For one thing, a quick package database query, equery belongs or equery files, here on gentoo, to see what files match a partial name, tends to be a pretty effective way to search for such things. I know as I routinely use that method. =:^) But now I know without actually having to go looking as you so kindly posted the info. =;^) > However they are clearly a user setting - it's the user who disables > them or (if they know which rc-files to edit) re-enables them, they > aren't a system setting. To be clear: I mean the user should have the > ability to enable/disable them for his user account, the equivalent of > what he can do now only be editing the rc-files in ~/.kde4. Not that > users should be able to delete or add the .desktop files from > /usr/share/autostart. But that's my point. The user has the ability to add the entries to autostart if they want to (and if they're already running there's already a UI available to disable them), entirely separate from the way kde normally manages the system default entries. And that's the way it should be. The two setups should remain separate, so a user is always clear on the entries he's added himself, vs those managed by the system. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
On Fri, 03 Jun 2011 11:28 +, "Duncan" <1i5t5.dun...@cox.net> wrote: > Klipper actually does, tho it's not necessarily intuitive. > > If you select quit from the second menu (the one you get if you click the > tear-off, otherwise it shows only some of the possible entries and misses > the actual klipper app options, at least if you have it set to more > entries than the first menu shows normally, I have it set to 50... I'd > call the fact that it doesn't append the app options to the first menu a > bug...), in what would be the normal "are you sure" dialog, it instead > asks if you want to start it automatically when you login, with start, > do- > not-start, and cancel buttons (thus giving you the are you sure option > indirectly, as cancel). > > But selecting quit to configure whether you want to start it at login is > about as unintuitive as the infamous MS Windows start button... to > logoff/ > shutdown! > > Actually, I'd call /that/ the bug. It should have a rather more > intuitive > option to start at login directly in the klipper config dialog. You > shouldn't have to quit it to set that, altho having it in the quit > verification is a nice touch as well, but only as well, that shouldn't be > the ONLY way of setting it. Your forgetting the problem that caused me to start this thread originally: When you disable one of these programs from starting with KDE by right-clicking on it and clicking 'quit' there is no way to re-enable them. There is no way to even see what's disabled or enabled - it just dissapears into the ether from the user's POV, like my KNetworkManager. The only way is if the user searches on mailing lists and forums and discovers that the 'clipboard thing' in their task bar is called kclipper or something and they have to edit a some config file. > > It's still not a bug not to appear in the /user/ autostart area, because > it's a kde service and is treated as such (the monochromatic icon is a > major hint), not an additional normal user app. > > Actually, I expect eventually they'll have it appear in the systray > "extra > items" list with a checkbox to start it there, much as they do device > notifier and event notifier (notifications). If you check existing bugs, > there's still menu/window/shortcut bugs open resulting from the 4.5 move > to the monochromatic icons and system-tray services, and it really does > feel like what we have ATM is a hack-job temporary workaround designed to > get it workable after that, not the final UI solution it should be. > > But that's klipper. I really can't have a proper opinion on knetmanager, > since I don't have it installed, except that I don't believe it's a bug > not to show it in autostart unless you as the user have directly > configured it there, because that's what autostart is /for/, the stuff > you've put there yourself, not the system services stuff kde normally > handles on its own. And that's really an opinion about the autostart > kcontrol module, not knetworkmanager, except that knetworkmanager happens > to be one of the apps in question. Well maybe these things that are defined in /usr/share/autostart should appear as services in the Startup & Shutdown module, but they don't. However they are clearly a user setting - it's the user who disables them or (if they know which rc-files to edit) re-enables them, they aren't a system setting. To be clear: I mean the user should have the ability to enable/disable them for his user account, the equivalent of what he can do now only be editing the rc-files in ~/.kde4. Not that users should be able to delete or add the .desktop files from /usr/share/autostart. Tim ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards posted on Fri, 03 Jun 2011 11:02:09 +0200 as excerpted: > Klipper also has no option to re-enable it's startup if > disabled. > > This is not something most desktop users should have to do and defeats the > purpose of the Startup & Shutdown module. > > I'll raise a bug. Klipper actually does, tho it's not necessarily intuitive. If you select quit from the second menu (the one you get if you click the tear-off, otherwise it shows only some of the possible entries and misses the actual klipper app options, at least if you have it set to more entries than the first menu shows normally, I have it set to 50... I'd call the fact that it doesn't append the app options to the first menu a bug...), in what would be the normal "are you sure" dialog, it instead asks if you want to start it automatically when you login, with start, do- not-start, and cancel buttons (thus giving you the are you sure option indirectly, as cancel). But selecting quit to configure whether you want to start it at login is about as unintuitive as the infamous MS Windows start button... to logoff/ shutdown! Actually, I'd call /that/ the bug. It should have a rather more intuitive option to start at login directly in the klipper config dialog. You shouldn't have to quit it to set that, altho having it in the quit verification is a nice touch as well, but only as well, that shouldn't be the ONLY way of setting it. It's still not a bug not to appear in the /user/ autostart area, because it's a kde service and is treated as such (the monochromatic icon is a major hint), not an additional normal user app. Actually, I expect eventually they'll have it appear in the systray "extra items" list with a checkbox to start it there, much as they do device notifier and event notifier (notifications). If you check existing bugs, there's still menu/window/shortcut bugs open resulting from the 4.5 move to the monochromatic icons and system-tray services, and it really does feel like what we have ATM is a hack-job temporary workaround designed to get it workable after that, not the final UI solution it should be. But that's klipper. I really can't have a proper opinion on knetmanager, since I don't have it installed, except that I don't believe it's a bug not to show it in autostart unless you as the user have directly configured it there, because that's what autostart is /for/, the stuff you've put there yourself, not the system services stuff kde normally handles on its own. And that's really an opinion about the autostart kcontrol module, not knetworkmanager, except that knetworkmanager happens to be one of the apps in question. But if you put it there yourself (as I did kicker, note that whatever I choose in that above should kicker start at login dialog, it doesn't remove it from the user's autostart config, nor should it, since I put it there myself and it should stay there until I remove it myself), THEN it should be there. THAT would not be a bug. In fact, if kde added or removed an entry in autostart based on any action other than the user doing it themselves either thru the kcontrol/autostart module GUI or by directly adding/removing the files from the associated directories, THAT would be a bug. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
On Fri, 03 Jun 2011 03:51 +, "Duncan" <1i5t5.dun...@cox.net> wrote: > > FWIW, both klipper and krandrtray have files in my *.desktop autostart > dir > (the path of which I've customized to ~/config/autostart/ , no initial > dot > as I don't like hidden files/dirs so much). > > However, I deliberately placed at least the klipper entry there myself > after kde quit starting it on its own for some reason. It was NOT there > originally, even when kde was starting it properly. I don't remember > putting the krandrtray entry there but I do remember deciding to run it > regularly, recently, tho I /thought/ I'd checked a box in its config to > do > so, but can't see that box now so I don't know if I'm recalling what I > did > to set it auto-run or not. > > HOWEVER, my main point in the previous reply was that kde has several > ways > to start apps, and that normally the only ones found in the autostart > kcontrol applet are the ones specifically put there by the user. The > ones > normally started by the system or with a checkbox in the app config > itself > as to whether they run on kde start or not, don't appear in that module > (or the associated directories) because it's not a manual user initiated > change, but rather part of kde's own infrastructure. > > That's not a bug. That's a designed feature! > > (I did speculate, however, that an entry might appear in the service > manager module also located under startup and shutdown, if the app was > installed. But I don't have it installed so I can't check.) If it really is a feature and not just an oversight in the design of the Startup & Shutdown module then it's a mis-feature. There's no reliable way for the (normal) user to enable or disable these programs starting with KDE - most of them simply don't have an option in the app config. KNetworkManager would be the perfect example of this, once disabled you can never re-enable it unless you hack a config file in an undocumented procedure. Klipper also has no option to re-enable it's startup if disabled. This is not something most desktop users should have to do and defeats the purpose of the Startup & Shutdown module. I'll raise a bug. Tim ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards posted on Thu, 02 Jun 2011 22:39:10 +0200 as excerpted: > First off, thanks for the detailed explanation of the autostart > locations, I've saved it to a text file as a reference. > > However the problem is that although all those autostart locations you > detailed are managed by the Startup & Shutdown control centre module > nothing resembling networkmanager appears in that control centre module. > I think that's at least 2 bugs: > > 1) The fact that KDE scans rc-files in some fashion to start programs, a > behaviour that sounds hacky and probably isn't documented anywhere but > in the code itself. These programs should appear properly in Startup & > Shutdown->Services > > 2) A bug in knetworkmanager that it doesn't register itself in Startup & > Shutdown->Services > > Not to mention that it's not the only program that does this. Going > through the icons in my control bar I see the following programs that > start with KDE, do not appear in Startup & Shutdown module and are not > widgets: > Klipper (.kde4/share/config/klipperrc) > Kmix (.kde4/share/config/kmixrc) > Size Change and Rotate (.kde4/share/config/krandrrc) > Korganizer Reminder Module (.kde4/share/config/korgacrc) > > So if you have any of the following installed on your machine you'll be > able to see the same behaviour. FWIW, both klipper and krandrtray have files in my *.desktop autostart dir (the path of which I've customized to ~/config/autostart/ , no initial dot as I don't like hidden files/dirs so much). However, I deliberately placed at least the klipper entry there myself after kde quit starting it on its own for some reason. It was NOT there originally, even when kde was starting it properly. I don't remember putting the krandrtray entry there but I do remember deciding to run it regularly, recently, tho I /thought/ I'd checked a box in its config to do so, but can't see that box now so I don't know if I'm recalling what I did to set it auto-run or not. HOWEVER, my main point in the previous reply was that kde has several ways to start apps, and that normally the only ones found in the autostart kcontrol applet are the ones specifically put there by the user. The ones normally started by the system or with a checkbox in the app config itself as to whether they run on kde start or not, don't appear in that module (or the associated directories) because it's not a manual user initiated change, but rather part of kde's own infrastructure. That's not a bug. That's a designed feature! (I did speculate, however, that an entry might appear in the service manager module also located under startup and shutdown, if the app was installed. But I don't have it installed so I can't check.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards wrote, On 06/02/2011 02:10 PM: > Thanks for the script. I'm not sure what you mean exactly. The config path is: > config = > /home/tim/.kde4/share/config/:/usr/share/kde4/config/:/etc/kde4/share/config/ > [/usr/share/kde4/config/] > > Does that mean KDE scans all those directories for rc-files, and then starts > any that have autostart=true? No, I think what you're really looking at (i could be wrong), is that the "networkmanager" desktop autostart file (on my Debian Squeeze machine, this is located in /usr/share/autostart/kde-4-knetworkmanager-autostart.desktop ) has an execution conditional in it... X-KDE-autostart-condition=networkmanagementrc:General:Autostart:true So, in order to autostart networkmanager, it needs to find a configuration key named "Autostart" within the "General" group of the networkmanagementrc configuration file that is true. $ kreadconfig --file networkmanagementrc --group General --key Autostart (i don't have such a key in my config search path) So, it must default to 'true', I suspect that you have it set FALSE somewhere. $ kde4-config --locate networkmanagementrc --path config /home/sdowdy/.kde/share/config/networkmanagementrc This is the file that is found first within the config path To force Autostart to True, do... kwriteconfig --file networkmanagementrc --group General --key Autostart true That will write it into the first path component in the "config" path (for you: /home/tim/.kde4/share/config/networkmanagementrc) So, the *autostart* files are separate from the configuration files, but because the networkmanager desktop autostart file is making a demand for a config path conditional, the config stuff gets pulled into the mix here. >From quickly glancing at another message of yours. Those other applications are probably configured in the KDE4 system autostart install path, thus not *user* managed. My 'kde4-info' script doesn't identify that path (because kde4-config doesn't show it either), but as you see from above it is /usr/share/autostart. This brings up a point about *Disabling* those system installed defaults. Theoretically, they should all have a 'X-KDE-autostart-condition' directive so the user could create disabling overrides. But notice they don't all: $ grep -c X-KDE-autostart-condition /usr/share/autostart/* /usr/share/autostart/kab2kabc.desktop:1 /usr/share/autostart/kaddressbookmigrator.desktop:1 /usr/share/autostart/kalarm.autostart.desktop:1 /usr/share/autostart/kgpg.desktop:1 /usr/share/autostart/klipper.desktop:1 /usr/share/autostart/kmix_autostart.desktop:1 /usr/share/autostart/konqy_preload.desktop:1 /usr/share/autostart/korgac.desktop:1 /usr/share/autostart/krunner.desktop:0 /usr/share/autostart/nepomukserver.desktop:1 /usr/share/autostart/plasma-desktop.desktop:0 /usr/share/autostart/restore_kmix_volumes.desktop:1 So, it is presumed that you MUST run krunner and plasma-desktop on my machine. I wanted to replace 'plasma-desktop' with one that started 'plasma-desktop --graphicssystem=raster'. From what little documentation i ran across there was a method of a user created autostart OVERRIDE of a system autostart. I.E. create the same filename and disable it from running. Then i was going to create a 'plasma-desktop-rastergraphics.desktop' that invoked the command above, instead. Unfortunately, Debian Squeeze forcibly deletes any 'plasma-desktop.desktop' file in the user's autostart directory in 'startkde' to address some other bug. I think that solution is itself a bug, breaking this override mechanism (as i understand it) Oh well, there are plenty of other significant bugs in KDE4 i'm having to deal with. (kquitapp plasma-desktop && sleep 3 && plasma-desktop --graphicssystem=raster) then has to become a KDE4 "Autostart" script to workaround this particular bug :-( Hopefully that answers your question... --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
On Thu, 02 Jun 2011 14:54 +, "Duncan" <1i5t5.dun...@cox.net> wrote: > Tim Edwards posted on Thu, 02 Jun 2011 11:53:52 +0200 as excerpted: > > > Recently I found that knetworkmanager wasn't starting up when I logged > > into KDE. I tried looking for any mention of it in the 'startup and > > shutdown' control centre module, but no luck. Eventually I found a tip > > on a forum that I had to set 'Autostart=true' in > > ~/.kde4/share/config/networkmanagementrc > > FWIW I don't use networkmanager at all, here. I have two main systems > here. My workstation is setup with a constant wired Ethernet connection > that's started as one of the system init services. My netbook... isn't > really used as a /net/book but rather as a portable un-networked computer > most of the time. Its Ethernet, which I use for updating from the > dedicated 32-bit chroot system image on my otherwise 64-bit workstation, > is likewise initscript controlled but in a non-default runlevel, and its > wireless hasn't been a big priority for me. I did try to get the netbook > wireless networking running at one point but failed, I believe due to a > kernel bug with the particular kernel I was running at the time. I've > since upgraded kernels but as I said, it hasn't been a big priority to > get > that working, and I've not gotten back to it. > > As such I can't and won't attempt to deal with the networkmanager stuff > at > all. However, I can help with the following... > > > So my question is, what's the status of the autostart stuff: Shouldn't > > it all be configurable through the standard control centre module which > > stores its settings in the standard (~/.config/autostart) > > directory? > > Not really. The setting found in that location serve a specific purpose > -- USER configurable autostart (and auto-stop). It's not for general > KDE/ > desktop services (there's a different place to configure that) or for > general system services (configured using whatever tools your > distribution > provides for setting up and configuring system initscripts and services). > > > Does KDE go scanning through ~/.kde4/share/config/ looking for > > 'Autostart=' in rc-files? > > I don't believe so in general. However, knetworkmanager is evidently > (the > caveat about my not running it here applies, thus "evidently", based > purely on the evidence you reported above) available as a kde desktop > service if so configured, and this is /evidently/ the config-file > location > where that preference is stored. Presumably there's also a GUI option > controlling it somewhere, but since I don't have the software installed, > I > can't be sure where that might be. First off, thanks for the detailed explanation of the autostart locations, I've saved it to a text file as a reference. However the problem is that although all those autostart locations you detailed are managed by the Startup & Shutdown control centre module nothing resembling networkmanager appears in that control centre module. I think that's at least 2 bugs: 1) The fact that KDE scans rc-files in some fashion to start programs, a behaviour that sounds hacky and probably isn't documented anywhere but in the code itself. These programs should appear properly in Startup & Shutdown->Services 2) A bug in knetworkmanager that it doesn't register itself in Startup & Shutdown->Services Not to mention that it's not the only program that does this. Going through the icons in my control bar I see the following programs that start with KDE, do not appear in Startup & Shutdown module and are not widgets: Klipper (.kde4/share/config/klipperrc) Kmix (.kde4/share/config/kmixrc) Size Change and Rotate (.kde4/share/config/krandrrc) Korganizer Reminder Module (.kde4/share/config/korgacrc) So if you have any of the following installed on your machine you'll be able to see the same behaviour. Tim ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Stephen Dowdy posted on Thu, 02 Jun 2011 09:10:15 -0600 as excerpted: > I was surprised when using the kcmshell4 autostart center that it was > using the XDG autostart path to write a new autostart desktop function. > I thought it would prefer the KDE4 autostart path. I'm not sure if that > indicates a future deprecation of the KDE4 specific autostart directory > in favor of XDG integration? Our first replies crossed and you evidently didn't see mine before you posted. I (believe I) covered that there and you will have probably seen it by now, but just in case, a quick summary... The XDG autostart path is for *.desktop files, while the kde autostart path is for executables/scripts, so it's not that one's being deprecated (to my knowledge at least) but that they serve two different purposes There's also the kde shutdown and pre-start/env dirs/paths, making four locations in total, each with its own purpose. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards wrote, On 06/02/2011 03:53 AM:
> Recently I found that knetworkmanager wasn't starting up when I logged
> into KDE. I tried looking for any mention of it in the 'startup and
> shutdown' control centre module, but no luck. Eventually I found a tip
> on a forum that I had to set 'Autostart=true' in
> ~/.kde4/share/config/networkmanagementrc
>
> So my question is, what's the status of the autostart stuff:
> Shouldn't it all be configurable through the standard control centre
> module which stores its settings in the standard (~/.config/autostart)
> directory?
> Does KDE go scanning through ~/.kde4/share/config/ looking for
> 'Autostart=' in rc-files?
Tim,
In case it's any help, i enclose a script that dumps out the KDE4 configuration
operational environment in a nice concise format.
There would be a difference between the autostart path and the config path.
The config path would be scanned until it finds a "networkmanagementrc" file.
I believe
kde4-config --locate networkmanagementrc --path config
would show which file ultimately is going to be used. (i think it's a scan
and stop on first found algorithm, rather than a merge all files found
that match in the path operation). it'll show nothing if no config file
is found in the path.
I was surprised when using the kcmshell4 autostart center that it was using
the XDG autostart path to write a new autostart desktop function. I thought
it would prefer the KDE4 autostart path. I'm not sure if that indicates
a future deprecation of the KDE4 specific autostart directory in favor
of XDG integration?
If so, you may need to use the 'OnlyShowIn=KDE' directives in such XDG pathed
autostart files if the given application can't or shouldn't run in other
desktop environments.
--stephen
#!/bin/sh
# Get some Configuration info on KDE
echo "[VersionInfo]"
#kdeconf() { kde3-config "$@" ;} # KDE3
kdeconf() { kde4-config "$@" ;} # KDE4
kdeconf --version
# http://techbase.kde.org/KDE_System_Administration/Environment_Variables
echo ""
echo "[Environment]"
while read var default; do
printf "%24s = %s\n" "${var}" "$(eval echo \${$var-${default}\(\*\)})"
done<<"EOF"
KDE_FULL_SESSION
KDE_SESSION_UID
KDE_SESSION_VERSION
KDEWM kwin
KDE_DISPLAY
KDE_MULTIHEAD
KDEDIRS
KDEHOME ${HOME}/.kde
KDE_HOME_READONLY
KDEROOTHOME ~root/.kde
KDESYCOCA
KDETMP /tmp
KDEVARTMP /var/tmp
KDE_LANG
KDE_UTF8_FILENAMES
KDE_NO_IPV6
KDE_USE_IDN at:ch:cn:de:dk:kr:jp:li:no:se:tw
KDE_IS_PRELINKED
KDE_MALLOC
KDE_NOUNLOAD
KDE_DOUNLOAD
KDE_DEBUG
KDE_DEBUG_NOPROCESSINFO
KDE_DEBUG_NOAREANAME
KDE_DEBUG_NOMETHODNAME
KDE_DEBUG_FILELINE
KDE_DEBUG_TIMESTAMP
KDE_COLOR_DEBUG
KDE_FORK_SLAVES
EOF
echo "(*) indicates variable unset and a default value substituted"
echo ""
echo "[Configuration]"
while read option; do
printf "%18s = %s\n" "${option}" "$(kde4-config --${option})"
done<<"EOF"
prefix
exec-prefix
libsuffix
localprefix
qt-prefix
qt-binaries
qt-libraries
qt-plugins
EOF
# --kde-version Compiled in version string for KDE libraries
# --locate filename Find filename inside the resource type given to
--path
echo ""
echo "[UserPaths]"
#KDE3#for upath in desktop trash autostart document; do
for upath in desktop autostart document; do
printf "%18s = %s\n" "${upath}" "$(kdeconf --userpath ${upath})"
done
echo ""
echo "[Paths]"
while read ktype ksep kdescription; do
# printf "PATH(${ktype}) [${kdescription}]\n $(kdeconf --path ${ktype})\n"
printf "%18s = %s [%s]\n" "${ktype}" "$(kdeconf --path ${ktype})" "$(kdeconf
--install ${ktype})"
done <#!/bin/sh
# Get some Configuration info on XDG
echo "[Environment]"
while read var default; do
printf "%24s = %s\n" "${var}" "$(eval echo \${$var-${default}\(\*\)})"
done<<"EOF"
XDG_DATA_HOME ${HOME}/.local/share
XDG_CONFIG_HOME ${HOME}/.config
XDG_DATA_DIRS /usr/local/share/:/usr/share/
XDG_CONFIG_DIRS /etc/xdg
XDG_CACHE_HOME ${HOME}/.cache
XDG_RUNTIME_DIR
EOF
echo "(*) indicates variable unset and a default value substituted"
echo ""
echo "[Settings]"
while read var desc; do
printf "%24s = %s\n" "${var}" "$(xdg-settings get "${var}")"
done<___
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
On Thursday, June 02, 2011 10:53:52 AM Tim Edwards wrote: > Recently I found that knetworkmanager wasn't starting up when I logged > into KDE. I tried looking for any mention of it in the 'startup and > shutdown' control centre module, but no luck. Eventually I found a tip > on a forum that I had to set 'Autostart=true' in > ~/.kde4/share/config/networkmanagementrc > > So my question is, what's the status of the autostart stuff: > Shouldn't it all be configurable through the standard control centre > module which stores its settings in the standard (~/.config/autostart) > directory? > Does KDE go scanning through ~/.kde4/share/config/ looking for > 'Autostart=' in rc-files? > You might like to check System Settings > Startup and Shutdown > Autostart section. I've no idea whether there are other places being read. Anne -- New to KDE Software? - get help from http://userbase.kde.org signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards posted on Thu, 02 Jun 2011 11:53:52 +0200 as excerpted: > Recently I found that knetworkmanager wasn't starting up when I logged > into KDE. I tried looking for any mention of it in the 'startup and > shutdown' control centre module, but no luck. Eventually I found a tip > on a forum that I had to set 'Autostart=true' in > ~/.kde4/share/config/networkmanagementrc FWIW I don't use networkmanager at all, here. I have two main systems here. My workstation is setup with a constant wired Ethernet connection that's started as one of the system init services. My netbook... isn't really used as a /net/book but rather as a portable un-networked computer most of the time. Its Ethernet, which I use for updating from the dedicated 32-bit chroot system image on my otherwise 64-bit workstation, is likewise initscript controlled but in a non-default runlevel, and its wireless hasn't been a big priority for me. I did try to get the netbook wireless networking running at one point but failed, I believe due to a kernel bug with the particular kernel I was running at the time. I've since upgraded kernels but as I said, it hasn't been a big priority to get that working, and I've not gotten back to it. As such I can't and won't attempt to deal with the networkmanager stuff at all. However, I can help with the following... > So my question is, what's the status of the autostart stuff: Shouldn't > it all be configurable through the standard control centre module which > stores its settings in the standard (~/.config/autostart) > directory? Not really. The setting found in that location serve a specific purpose -- USER configurable autostart (and auto-stop). It's not for general KDE/ desktop services (there's a different place to configure that) or for general system services (configured using whatever tools your distribution provides for setting up and configuring system initscripts and services). > Does KDE go scanning through ~/.kde4/share/config/ looking for > 'Autostart=' in rc-files? I don't believe so in general. However, knetworkmanager is evidently (the caveat about my not running it here applies, thus "evidently", based purely on the evidence you reported above) available as a kde desktop service if so configured, and this is /evidently/ the config-file location where that preference is stored. Presumably there's also a GUI option controlling it somewhere, but since I don't have the software installed, I can't be sure where that might be. But, I can explain a bit more about autostart in general... First, it's useful to name the ways that kde does autostart. These are the ones I am as a user aware of, in general from the surface-most to the deepest infrastructure: 1) KDE session. This is controlled via kcontrol[1][2], system administration, startup and shutdown, session management, under "on login". If you set restore previous session (as I have), kde will restart the apps that you had running when you logged out, with the exception of anything listed in the exceptions list. Alternatively, you can elect to restore a manually saved session. The help for this item says that if it's checked (I don't know since I use the restore previous session option), there's a save session option added to the leave menu, along with the others. The third alternative is to start with an empty session. At this level, kde autostart is controlled by whatever it found running when it saved the session, either when that option was chosen if save session is set, or at logout, if that setting is set. If you use empty session, you're simply telling kde not to autostart anything at this level. 2) The autostart functionality I believe you were referring to. The GUI for this is kcontrol, system administration, startup and shutdown, autostart. The GUI provided actually controls four different launch options with differing purposes in one place. 2a) Desktop files. This is the freedesktop.org standard *.desktop file launch option. The *.desktop files in question can be found in $XDG_CONFIG_HOME/autostart. The default for XDG_CONFIG_HOME if that variable is unset, is $HOME/.config/, so the default location is ~/.config/autostart/ , if you wish to manually add your own *.desktop files. Once they are added, if you select one and hit advanced, there's an option to autostart in kde only, which adds an appropriate line to the *.desktop file. If this isn't set, any freedesktop.org compliant environment (gnome and xfce I believe, probably others as well) should see and launch these apps when the user logs in. 2b) What the kcontrol autostart GUI lists as script files is actually three separate options, as once you add a script using the GUI, there's a dropdown box allowing you to select startup, shutdown, or pre-kde-startup. Scripts in question should be set executable and named as *.sh. (The startup option lets you use any name, but if you change it to shutdown or
