I’ve been working with a lot of different distributions out there the past few days and haven’t found one that I like that has KDE 4.2 packages.  Experimenting further brought me back to my old friend Conary and Foresight Linux.  For those of you that don’t know what Conary is, I’ve written a Part 1 (I never finished Part 2 as I changed jobs and haven’t found the motivation) on what Conary attempts to accomplish and a bit of background on how it does things.

When I think of Foresight and rPath Linux along with Conary, I come to a direct comparison to Arch Linux…because pacman is quite similar.  The main difference is that Foresight does a lot more for you out of the gate than Arch does…and arch is quite a bit faster than Foresight.  Still, I decided to give KDE 4.2 a go on Foresight to see how it’s been progressing.

 The first thing I needed to do was to change from the 2 branch of Foresight to the 2-qa branch.  The reason for this is that 2-qa houses python 2.6, which is needed for KDE 4.2.  Until python 2.6 is pushed into the stable branch of Foresight, you’ll need to move your installation to the 2-qa branch.  First, using your favorite text editor, edit /etc/conary/config.d/foresight file.  Inside that file, you’ll see next to the line InstallLabelPath the following:

installLabelPath foresight.rpath.org@fl:2-kernel  foresight.rpath.org@fl:2 conary.rpath.com@rpl:2-qa

change this to the following:

installLabelPath foresight.rpath.org@fl:2-qa-kernel  foresight.rpath.org@fl:2-qa conary.rpath.com@rpl:2-qa

or you can substitute 2-devel there if you’d like to move to the 2-devel branch:

installLabelPath foresight.rpath.org@fl:2-devel-kernel  foresight.rpath.org@fl:2-devel conary.rpath.com@rpl:2-qa

Now, let’s migrate the system.  Migration to a different branch will result in moving your system to become EXACTLY like the branch you’re migrating to.  That means that any custom applications you have installed may be removed…conary will make your system become EXACTLY what 2-qa says it should.  This is the reason I recommend performing these tasks with a fresh install before customizing.

Change with the following command:

sudo conary migrate group-gnome-dist=@fl:2-qa --keep-required --resolve

Don’t worry, 2-qa is not as unstable as it sounds…the most unstable branch of Foresight is 2-devel.  To compare these branches to Debian, 2-qa is like testing while 2-devel is like unstable. 

I installed Foresight Linux 2.0.6 Gnome using a DVD on a Dell D630 Latitude.   Next, I like to uninstall the stuff that is extra in Gnome that I don’t use (you could say, I strongly do not like these):

sudo conary erase transmission f-spot evolution evolution-exchange tomboy banshee

With those packages out of the way, I did a full update.

sudo conary updateall

Some early Foresight 2.0.6 kernels cause random disconnects for my wireless chipset on the Dell Latitude D630 (Intel Pro Wireless) but after the upgrade this symptom isn’t present.  The default 2.6.27.5 kernel made way for the 2.6.27.10 and it seems to work for me quite nicely.  I did notice that the 2.6.27.10 kernel had some sound abnormalities for me with the Intel HDA sound card…so I rolled back to the 2.6.27.5 and things worked great.  See this issue for more information on this sound issue.

Now we have a completely “useable” Gnome system on our hands…but we can’t have that unusable system now can we? (easy Gnome supporters…tis only a joke).  Let us get a real desktop like openbo…er…KDE on there!  Before I got too far though, I wanted to make sure I could play mp3′s and other restricted format items so I installed the codecs needed:

sudo conary update group-codecs

Once this has finished, let’s get KDE 4.2 up and running.

sudo conary update group-kde4=kde.rpath.org@fl:2-kde4.2-devel

Once that command has completed, you should be able to logout and log back in to KDE 4.2.  The most recent builds of KDE 4.2 include python 2.6…something that Foresight Linux has been slow on the uptake with due to conary being written in python.  I’m still working on testing everything…I’m not sure how well this newest build works.  Look for a status update in a few days on this…

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...

Related posts brought to you by Yet Another Related Posts Plugin.

Foresight Linux and KDE 4.2 originally appeared on Yet Another Linux Blog on February 3, 2009.

The thing that boggles my mind is that everyone says Gnome is better for a Windows convert taking his/her Linux steps for the first time.  I have to disagree based on the experience I’ve had with conversions of new users from Windows.  I think KDE gives the best experience for a new Windows user…it’s familiar or at least feels familiar…things are in similar places to Windows.

I’d say that 80-90% of the users I convert across to using Linux prefer KDE to Gnome.  I always wonder why people think Gnome is so new user friendly.  Since I’ve always wondered, perhaps some Gnome users can tell me, what usability reasons do you have for using Gnome vs. KDE?  I’ve often heard that Gnome has integration and simplicity as the main reason…but could I not argue the same for KDE?  I’m looking for usability issues here and not specific bugs that cause you to drop one on its head.  Bugs can be fixed.  I’m talking about hard features that lack from one environment to the other.  What makes you use it in Ubuntu versus KDE?  Remember, not bugs…features!  Please let me know which desktop you prefer below and don’t forget to let me know the reason in the comments section below.

Related posts:

1. Convert PNG to GIF via Command Line I installed a bare bones Arch Linux system today and...

Related posts brought to you by Yet Another Related Posts Plugin.

Is Usability Really Simplicity? originally appeared on Yet Another Linux Blog on December 10, 2008.

Then I decided to search KDE-Apps.org and viola! I found it. A handy little tool that allows you to right click on any archive and “extract here” with Ark. Here’s how to install it.

cd ~/.kde/share/apps/konqueror/servicemenus
wget http://www.kde-apps.org/CONTENT/content-files/58251-extract_archive.tar.gz
tar xvf 58251-extract_archive.tar.gz
rm -rf 58251-extract_archive.tar.gz

Now right click on any archive and you should have the ability to “extract here” through the extract archive menu listing. You can also “extract to” any directory. Obligatory screenshot to follow. Hope this helps everyone out!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

KDE: Right Click, Extract Here originally appeared on Yet Another Linux Blog on July 10, 2008.

Those of you interested in helping us develop, package, or use KDE are welcome to join us in IRC #foresight-kde freenode.  Plans are to build a 3.5.9 Stable version and wait until 4.1 is released to push out a 4.1 version.  Of course, we’ll have 4.0.X builds available for testing and fun all the while   Please, lend us a hand and file those bug reports!

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...
2. Foresight, rPath, LiveCD, and Unity Linux Most, if not all, top distributions of Linux ship a...

Related posts brought to you by Yet Another Related Posts Plugin.

Foresight KDE Alpha-Alpha-Pre-Alpha-Pre Screenshot originally appeared on Yet Another Linux Blog on April 22, 2008.

For those of you with developer status or above on the Foresight Linux project, there is a KDE build available for testing (along with XFCE if you really have ambitions). Login to rBuilder Online, Click on the Foresight Linux Project, go to Manage Builds and search for Foresight Linux KDE Alpha3 and click it (DVD only). I downloaded and tested this build release to see how things are going.

Foresight KDE inherits all the goodness from the Foresight Linux project. This means the install is tar based and completes in less than 7 minutes. It also means Syslinux, Compiz Fusion, and more from the Release Notes. If you are interested in helping us develop further, please visit us in freenode #foresight-kde.

Findings

I found 3 major issues during testing. First, updateall fails with glibc errors. I worked over 6 hours on getting a solution and enlisted many in the community on helping me get past it. So far, no one has been able to provide a solution. The second issue is that pango is causing odd text to display on various applications: Pic1, Pic2. No solution to this as of the time of this writing. I’m assuming that an update to pango will cure this.

Third, gtk-qt-engine wasn’t installed by default so gtk applications looked quite nasty. A quick sudo conary update gtk-qt-engine got me rolling.

Observations

Things don’t look great. While the performance of the desktop was fine (no crashes, quite speedy) the default font/text looks horrible. The installed Theme is the default KDE one…no customization. My resolution/Monitor wasn’t detected so I was at 800×600 for resolution. Menu’s are chock full of junk (default applications) and have little organization.

Looking at this, one can tell it truly is based on an alpha release but I have to say that I’m still a bit disappointed. All of these observations were made during the last alpha release as well. At the time of that alpha release, I did not have enough Conary-foo™ (OK, so it’s not trademarked…) to make anything happen. Since I now have alpha3 up and running on my main system at home and am a bit further in my conary knowledge…you can bet I’ll be working on the aesthetics of Foresight KDE. Sure, the innards are more important than the shell…but the shell is the first thing seen by the user.

Hopefully, if there is an alpha4 (or beta1 for that matter) we’ll have the aesthetics worked out by then to give the user a pleasant “Foresight” experience.

KDE4 Status

KDE4 can be installed as well. It is still pulling in from SVN snapshots though so it is not as stable as I’d like it to be. Do this at your own risk! I do not have it permanently installed on my system. To install:

sudo conary update group-kde4=/kde.rpath.org@fl:2-kde4-devel

One of the benefits of conary is show above…installing KDE4 is as simple as one command I like to compare that with the Ubuntu/Debian way of doing it. Since there is no sources.list, you don’t have to mess with it. Conary remembers the branch the software came from inherently so it goes to those same places for that software unless you tell it not too explicitly. Imagine that! A package manager that is smart and allows you to maintain less! It also allows you to have both KDE3 and KDE4 installed side by side…but remember, both KDE4 and this build release of Foresight KDE are not production releases so things WILL change. In other words, don’t put this on a system you intend to keep.

It is my understanding that the KDE4 branch for Foresight KDE will soon be reverting out of SVN checkout builds to push stability as application portage continues.

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...

Related posts brought to you by Yet Another Related Posts Plugin.

Foresight KDE Alpha3 originally appeared on Yet Another Linux Blog on January 23, 2008.

As an example, a user might not like it if you tell them their bug will not be fixed for the next release. This is normal practice in many major distributions. But if you tell a user that their bug won’t be fixed through 4 releases, you may have a problem. Unfortunately, this also is becoming a normal practice for some major distributions.

I’ve been on both sides of the fence as a user and developer. I also managed a major community incentive for PCLinuxOS called mypclinuxos.com and coordinated PCLinuxOS Magazine (which now boasts a circulation of over 50k people). The main vehicle for the massive growth it went through was empowerment. If a user needed something done, we did it right away. If we couldn’t do it right away, we found a way to do it, met later, and did it then. The users felt actively enguaged in their software and took ownership of it. I tell you about these endeavors not to boast, but to show you that I know a little bit about communities and how to make them grow.

Bureaucracy be damned.

I feel sorry for organizations that get so hung up on organization that they forget that organizing isn’t just politics and data. Organizing is people too (Keep your Soylent Green jokes to a min).

What I think is happening in Ubuntu’s case is really something that effects all linux distributions out there…a lack of a QA process to deal not with quality of software but quality of service. A lack of a process to make sure simplistic bugs like the Aumix one and what happened to address it never happen again. I know they have a person that they recruited as a liaison to do this for them but one person and a handful of processes won’t cut it. It can be done by users if it is setup correctly and if Canonical would trust and empower its community to do the lifting for them.

I guarantee if Canoncical and Ubuntu asked its users to jump 85%+ of them would ask “How High?” The point of this post is that there aren’t a lot of distros out there that empower their users. When I first started developing add-on packages with my friend Josh for MEPIS Linux, we were ostracized from the community. I experienced empowerment when I changed to PCLinuxOS as my primary distribution. Now, as I join the development team of Foresight Linux (KDE Version) I also have experienced the attitude “the tools are there…use them and allow us to help you”.

It’s refreshing to find this twice.

I’ve never been an Ubuntu user. This doesn’t mean I think it’s crap. I think it has done fantastic things and innovated many things for Linux and the desktop. I think that Ubuntu may be beginning to lose focus though on what matters. Canonical still isn’t making money hand over fist and this “desktop” thing isn’t paying the bills. More attention is being focused on selling the server side of things to fund the desktop side of things (my opinion). I sure hope Ubuntu can change prescriptions in their community glasses to bring things more clearly into focus.

Related posts:

1. Foresight, rPath, LiveCD, and Unity Linux Most, if not all, top distributions of Linux ship a...

Related posts brought to you by Yet Another Related Posts Plugin.

Empowering the Linux Community originally appeared on Yet Another Linux Blog on January 18, 2008.

Distros have changed. In the past, they were made up of a small, tightly knit group collaborators working toward a common goal. With distributions today we now have an informal, large group of collaborators…some of which may not even be aware of the main goal of the distro. That informal collaborator may just want package foo version 2.2 included in his/her distribution so that he/she can use it on their desktop. How does that informal collaborator become empowered? How can the developers reap what that collaborator sows and harness the collective collaboration of thousands of informal contributors? The answer for many software projects is version control. But how can this system benefit package management?

What If?

What if you could combine SVN/CVS/git behavior and packages? What if when you build the package properly, it is checked into the software development tree. You’d be eliminating an entire step in the process (i.e. working more efficiently) and you’d reap all the benefits of version control (diff, merge, shadow, exports, rollbacks, tags, logs) with the actual software packages without losing the benefit of working with source or binaries. Thousands of contributions could be made in the form of ready to install packages that are CERTIFIED (see how this is possible later in this post) to work on the distribution. The contributions would come in on a version control branch designed by the distribution developers…say 1-contribs (much like a contribs rpm server would be)…but unlike most distributions, they would be certified to run on your distro before they even hit the contribs server/branch. Imagine the impact that this would have for bug testing alone.

Sound too good to be true? It’s not. It’s Conary and it is getting ready to go to version 2.0. Let’s take a look at some advantages that conary has over traditional package management and how it can empower the end user.

What Are The Advantages?
In standard distro land, packages are tracked by version/name. If you packaged wget 1.0.12, your package would include this version string in the name. What if someone else packages that same software up and names it something different than you did? What does this package with name wget-1.0.12-suse93-i586.rpm have as an advantage over wget-1.0.12-suse9.3-i586.rpm? As you might be able to tell, this is hard for a package management system to understand concepts of older or newer packages and what should be installed on a system. There is no automatic solution to this process in standard distro land. This is done manually by a developer. The developer selects which version of a package is included in the repository.

Regardless, relying on a name that is manually created and given means that dependency resolution with most distributions will break sometime. Repositories end up with version clashes, missed/overlooked patches, clashing names in between distros for the same package. A disconnect opens up between those developers working with packages…not just packages for a single desktop environment but various ones (KDE, Gnome, Openbox) because the only thing that connects them is a SVN or CVS tree. Updates to one branch do not always make it upstream. With conary, this problem is solved. It works using a distributed version tree and therefore changes always flow upstream from various branches that don’t have to be located in the same place as in traditional version control systems.

Ever done an apt-get upgrade and had only half of the packages install before a failure occurs? You may have a broken xorg after that half update was applied. In rpm land, if I updated and didn’t get through all my package installs I may end up with missing dependencies and a broken system. With Conary this NEVER happens. If an update will break the system, Conary automatically rolls back the changes so that your system is in the EXACT state it was when you began the update. This behavior is built into the package manager and happens automatically during attempted updates/upgrades. It can also be manually done to return to a state that existed before the update.

As an example, have you ever installed a group of software from a development/testing repository that you don’t want installed anymore? Don’t want to go through logs to find out what group of software you installed? Can’t remember each and every package name? With conary simply do a sudo conary rollback # where # is the number of updates you want to rollback to and conary will return your desktop to the state it was before that update.

More advantages…let’s say you’re out on rpmbone.net and you’re searching for the latest release of KAlbum. Which one do you pick out of the results

? If you see your distro represented, great! You’re set…until you need to update from that version. Will you remember what repository you got your software from so that you can get future updates? Will you add this repository to your repository sources list? This being the case you’re going to get a whole lotta updates from that new source unless you do some heavy pinning. Wouldn’t it be great if you didn’t have to remember? Wouldn’t it be great if your package manager would manage this for you as well? Conary does this lifting for you. If you install a conary package from a different conary repository, it REMEMBERS for you where you got it. No alteration of sources because there isn’t a sources file. There isn’t a list of repositories to manage. Conary remembers where all your software is from and tracks this as part of the version control.

Let’s say you roll your own rpm and make it locally on your own build environment. Upstream, the package you built is updated to a version above the local rpm/deb you’ve installed. It installs automatically over the top of your change when you update. With conary, this wouldn’t happen…it tracks local installation of conary packages as well and preserves them if you so desire.

There are countless other advantages that I won’t go into here. The advantages that I went over are meant to support the main point of this post which is that you can get more done by combining package management with version control. This turns one developer into many and allows for many collaborators to contribute certified packages into a distributed version tree repository. This is working smarter and not harder.

More Information on Conary

Certified Packages

Knowing as a developer that you’re getting a CERTIFIED version of a package onto a contribution server is a huge amount of stress relief. Certification occurs with the tool rMake, which “facilitates building packages consistently across computers with dissimilar environment”. If you click on the link to the rMake page, you’ll see plenty of the benefits of using such a tool to package software. rMake creates a chroot

and installs the package you are building in that chroot. Since a chroot is a pristine and unaltered environment, all packages can be certified to run in that pristine and unaltered environment. When a package is committed to a conary repository, you KNOW that it worked inside a chroot on a conary based system. Therefore, you have less to worry about with system conflicts. You’ll be able to build and test packages BEFORE they’re even committed to the repository.

With rMake, you don’t have to worry if that package will run on your distro…you only have to worry about the possibility of unforeseen conflicts…package foo won’t drop its use of dbus for package bar and package bar fails…and package bar was just contributed by Joe Schmoe onto your contribs server. This is what distributions SHOULD be allowed to concentrate on…conflicts between packages on an installed system and not dependency resolution or patch management. The place where developers work on conflicts should not be the packages themselves or the repository…it should be the users’ desktop.

Empowerment

Taking the worry that a package committed to the repository won’t work away, developers can empower users. Empowerment is a powerful tool in open source. Often times, a user of desktop linux becomes soured when he/she realizes that something doesn’t fit exactly what they want. For example, Joe Schmoe may want a software suite that isn’t included in the distributions repository. Should they learn how to roll an rpm or package a deb to do this? Can they? Will the developers trust the package when or even if it is submitted to the contribution server? Most likely not.

When Joe created his package, he created it on his local system. Dependencies that are unforeseen will be present in that package because Joe’s system differs from other installed systems. He didn’t package and test with a chroot to make sure that all his dependencies were resolved before submitting his package to the contribution server. If Joe were using Conary and rMake, developers wouldn’t have to worry about whether his package were up to where it needed to be…because in order for him to commit it to the contribs server it would have to have all dependencies resolved and would have to be built in a chroot before it is even submitted.

The ability to package and contribute packages is therefore available to standard users. The package is also IMMEDIATELY available for consumption by that end user…no waiting period for it to trickle down into stable…it was already stable when contributed. When it changes from 1-contrib to 1-devel, conary automagically tracks that move and updates from 1-devel in the future. It’s that smart. Developers are still in the driver seat and can control the overall flow of packages in the repository…the power still rests with them. But conary does all the lifting for them and often times the developer finds themselves letting conary manage things.

Imagine KDE and Gnome desktop distro developers working side by side and sharing fixes/patches and packages of common shared software…remember, with conary repositories, all changes can be seen by both development trees (KDE and Gnome) so the changes are automatic when put in place. Instead of having to push that fix to both branches of software, conary allows for fixes to be automatic between the two desktop development branches.

Work smarter, not harder. Conary can be an incredible tool that can empower users to contribute and merge different development trees seemlessly between various versions of software. Is there a learning curve? Of course! If you don’t know or understand the concepts of version control, you’ll have a bit of an uphill climb when learning conary. When learning to package, you’ll have to understand some of the classes and superclasses that are passed down so you can take advantage of not reinventing the wheel with each package you roll.

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...

Related posts brought to you by Yet Another Related Posts Plugin.

Thoughts on Package Management originally appeared on Yet Another Linux Blog on December 12, 2007.

Working on a separate 20 inch monitor with a distribution in development however is another story. The fonts didn’t look beautiful at all. After some installation of custom fonts, things looked better, but the resolution is a bit higher on this LCD at 1400×1050. Easy to fix right? Just increase the DPI in the KDE Control Center to 120 right? Not so fast…even when it’s set to 96×96 there, it isn’t always set to 96×96. So let’s take a look at how you can force KDE to run at the correct DPI for your monitor which will, in turn, make your fonts look MUCH better. For those of you who are satisfied with your fonts, you might want to check out the commands below to see if you’re running at the DPI you think you are.

Open Konsole and let’s check your resolution:

xdpyinfo | grep dimension

This will tell you what the actual resolution of X is on your desktop. Next, look at the DPI setting.

xdpyinfo | grep resolution

Surprised? I was. I found that at the high resolution I was running at, the DPI was set to 86×86 despite my attempts to force it to 96×96 in the KDE Control Center.

So how does one combat this? It takes a bit of calculation with a formula followed by a one line entry into your xorg.conf. Easy enough? Almost too easy…couldn’t the KDE programmers, say, employ a control center menu for this? It’s possible…let’s hope it’s in KDE 4.0.

FORMULA

First, the formula. Using the dimensions you found above, you’ll have to calculate 2 numbers…one for horizontal and one for vertical. As my resolution is 1400×1050, I will use this as the example. The formula is as follows:

displaysize = (<pixelsize>/DPI-Desired)*25.4

In my case, displaysize = (1400/100)*25.4. This equals 355. I wrote this down for later. Now I need to use 1050 (my vertical setting for resolution 1400×1050) in the same formula (displaysize =(1050/100)*25.4) which comes out to 266. Keep these two numbers handy…remember, if you want 96 or 120 DPI for your monitor…sub in those numbers for the DPI-Desired and divide your resolution by them as shown in the formula above.

EDIT XORG.CONF

Open up xorg.conf in your favorite text editor..for example, my favorite is kate so I issue the following command: Alt-F2 (a run dialog pops up) >> kdesu kate /etc/X11/xorg.conf. You’ll be prompted for your root password to access this file. After it opens, find the “Monitor” section. Just before “EndSection” place a line like the following (substitute the values you found using the formula above):

DisplaySize 355 266 # 1400×1050 100dpi

Your display size may be different…just remember to place horizontal first, followed by vertical. Now you’ll need to restart X. Close all your applications and hit Control-Alt-Backspace. Log back in and issue the command we used previously for DPI:

xdpyinfo | grep resolution

If you followed the directions above correctly, your altered DPI settings should display. Gnome does this through a handy menu that’s very easy to use. It’s head and shoulders above what KDE does with fonts and setting DPI. Using Gnome at work for the past 4 months has shown me the many areas that KDE falls behind…but it also shows me the many areas where Gnome just doesn’t get the job done. In this case, KDE fails horribly on configuring DPI for nice looking fonts. Luckily, I was able to assemble information from various places on the web to get the job done. The page that helped me the most was Matt Parnell’s Brain, a weblog that had an entry with this formula. I wanted to reproduce the information here with a bit more hand holding so new users would be able to use the tip without getting confused. Hopefully, this helps!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

KDE and Xorg, Fonts and DPI originally appeared on Yet Another Linux Blog on September 20, 2007.

I’ve not used many of the whiz bang functions of KDE and desktop Linux…I’ve been more of a browser, mail, and RSS type of guy for many years. Now that I’ve been using Linux at work and at home, I’ve been blessed with the opportunity to figure out how to do things that I’ve never done before. In this case, convert audio to .wav, .ogg, or .mp3 with ease. There is a tool called audiokonverter available in PCLinuxOS 2007 repositories that makes this a snap.

Open up Synaptic and do a search for Audiokonverter. Install it and accept all marked packages as well. Now, rip those CD’s or navigate to the audio files you want converted in Konqueror.

Once there, select all the files you want to convert and right click them. In the right click menu is a new option available for you…Actions >> Convert to. Select this option and convert to any format you so desire (ogg, mp3, aac, wav, and flac). Tell the pop up where to place the newly converted file and enjoy your music in its new format! What a fantastic tool that makes listening and managing music libraries so much easier.

Please note: There is only one caveat to this fantastic tool…it won’t convert music in your mounted samba shares. You’ll first have to copy the music to a local drive and convert it from there. Despite this limitation, it’s quite a fantastic tool!

UPDATE: Make sure you install the “lame” package in PCLinuxOS via Synaptic. This allows you to move from various formats of audio to mp3.

Related posts:

1. Convert PNG to GIF via Command Line I installed a bare bones Arch Linux system today and...

Related posts brought to you by Yet Another Related Posts Plugin.

Convert Audio with Ease in KDE originally appeared on Yet Another Linux Blog on August 16, 2007.

Now there are two ways to do this…kind of. Actually, there is only one way to get programs to autostart but there is another way you can have programs startup when you login…let’s look at both of them.

The First Way

First, go to the PC Menu (or kmenu) >> Run Command >> konqueror –profile filemanagement

When Konqueror opens, navigate to /home/user/.kde/autostart (replace user with your login name). Now minimize that window…we’ll come back to it later. Next up, click on the My Computer icon on your desktop (or for other users, open up Konqueror and put the following in the addressbar: system:/). When that opens, click on applications and minimize the window and place it side by side with the previously opened window.

Hieronymus has posted a helpful tip that simplifies the process above.  After opening up Konqueror, use the Go Menu and click the entry for “autostart” which will take you directly to the correct folder for the current logged in user.  Thanks Hieronymus for the tip!  Visit their homepage here.

You should have something that looks like the following:

Now go ahead and navigate to the application you want to autostart in the applications window. Find the one you want and drag-drop it with your mouse into the autostart window.

That’s it! The program will autostart the next time you login. Didn’t think it would be that easy right? Well, you can even drag and drop shortcuts from the PC (kmenu) menu as well into this window or even shortcuts from the desktop. You can also right click in the folder and create an application link as well…it’s very convenient.

The 2nd Way

The second method is called session saving. This allows you to save a session exactly as it is…perhaps you have email, xchat, and firefox open…you could save this exactly as it is and logout. When you log back in, you’ll have the exact same applications open and waiting for you.

To do this, Open the KDE Control Center. Navigate to KDE Components >> Session Manager. Check the box for on login “restore previous session” and click “apply”. Make sure you look at the bottom text input field for any applications you may not want to restore and list them there. If you don’t know what the application command is, right click on the shortcut and choose properties…and look for the command. If the application is in the PC Menu (kmenu) then right click on the application and choose ‘put into run dialogue’ which will tell you the command to put in the field.

That’s it as well…now when you log back in, you’ll have the same stuff you had open when you logged out

Hope this assists people in the journey with KDE and PCLinuxOS.

Related posts:

1. Adding Color to Bash List Command Part II I previously blogged about how to add color to the...

Related posts brought to you by Yet Another Related Posts Plugin.

Autostart Apps in PCLinuxOS 2007 (KDE) originally appeared on Yet Another Linux Blog on August 13, 2007.