I’m an Electronic engineer. I did several embedded projects with hardware and software interworking. So, I am somehow experienced in programming. I also had several projects in Windows in Delphi language. As I became familiar with Linux, it was always one of my wishes to contribute in this huge project. I even wrote some open source projects myself. Which are stored in Sourceforge.net site (autoppp, blackwar and jalaliapplet).
Actually I have some problems contributing to already started projects. To describe you my problems, I bring here Blur effect in KDE as an example and If you know answers of my questions, please do not hesitate to leave me a comment how to solve my problems.
Recently I installed Kubuntu 11.04 with KDE 4.6 on my laptop. Blur effect is enabled on Panel as is working there without any problem. But the problem is that transparent windows are not blurred. The scenario is always like this:

1. I searched Internet forums to find a solution for this problem. No joy.
   
2. I searched bug reports to find a solution for this problem. No joy.
3. I now want to go to KDE website to find out how can I contribute to this project because I want to solve this problem myself. Regardless of long texts about how to pay donations or introducing KDE to friends(!), It’s a little hard to find how to start developing the code.

I want to know:

1. Which source codes I must download to solve my problem with blue effect as I described above. How can I find which source file or which group of source files I must work on?
2. Which packages I need to download and Install to be able to compile the sources I downloaded?
3. After compiling the source code how can I installed the compiled code on my system?
4. How can I uninstall it to bring my system back to the previously installed KED?
5. What is SVN?

Thanks a lot people

OSS projects vary in accepting user contributions. Some are open and others are more tightly controlled. People have submitted patches to Firefox that are desired by many users and been turned down if it is something the core developers don't want to include. Just because someone invites you into their home, it doesn't mean they will let you paint the walls a different color. I don't know the specifics of KDE, you would have to look into who supports it and how open they are.

Changing it for yourself is another matter. You should be able to get all of the source in tarballs or srpm, unpack them, patch them and build them. As for switching back and forth - maybe. I have 6000+ files with the letters 'kde' in them on my system, and that's with no source installed. The easiest way would be to deploy your test builds to separate virtual machines, but you might be lucky and find the code you want to change isolated in one library somewhere.

I naively tried to make a change to Evolution, once. I never got past the first step of getting it to build. There were so many dependencies and conflicts on latest and greatest tools, libraries, kernel, etc. that I eventually gave up. I suspect the KDE team has their own build environment which may or may not be described in the READMEs.

Good luck.

Are you also familiar with C (and I do not mean C++)? All kernel bits and drivers for Linux are written in C, with some GCC specific twists. A lot of the software used in Linux distributions is written in C or C/C++, so you'll most likely need to know at least C.

The blur effect only works on Intel i915 and above integrated graphics controllers only. If you have that (you can see your hardware by running /sbin/lspci), then you may have run into an unfortunate driver change, which fortunately is easy to bypass by running WIN_DIRECT_GL=1 kwin –replace & in a terminal.

Your approach is not optimal. You should always first check your distribution's web site for known bugs (in this case, kubuntu.org and ubuntu.org, since Kubuntu is an Ubuntu variant). You should also try to find out where the problem could be. Each part is developed quite independently, and to find pertinent information, you need to find out which project to contact. A good way to do that is to look for similar, but not necessarily exactly the same, problems.

For example, if I have a graphics-related problem, I first Google for the problem keywords and my desktop environment. In your case, using +KDE +transparent +blur will yield the answer in the third hit, in a KDE forum post. If that did not work, I'd look at my distribution's (Kubuntu) forums and bug reports. If that did not work, I'd look at the desktop environment's (KDE) forums and bug reports. If that did not work, I'd look at the graphics stuff developers mailing lists (mostly here) and the Linux kernel mailing list archives (for example here).

1. Since your desktop environment is KDE, your window manager is kwin, so kwin sources is one possibility.
   If the issue were on the lower level, then you'd need to look at the driver for your graphics chipset. The basic low level stuff like graphics mode setting and connector control is in the kernel proper, the rest is in the X.org graphics driver for Intel chipsets.
2. That depends. For example, to get the necessary packages for kernel development in Ubuntu, you need a number of packages:

   fakeroot build-essential crash kexec-tools makedumpfile kernel-wedge
   build-dep linux
   git-core libncurses5 libncurses5-dev libelf-dev asciidoc binutils-dev

   but others usually need additional libraries and development packages. For Kwin, look here.
3. I've found it is easiest to create a package, and then install that new package, using whatever package manager the distribution uses.
   For Ubuntu variants, check if there is a related PPA here.
   The xorg-edgers PPA usually has the bleeding-edge graphics stuff.
   The reason is that the developers for the existing packages have already worked out how to create a working package from the sources. (This typically involves a patch and invoking debuild for .dep packages, a SPEC file and possibly patches for RPM packages, and so on). For example, the xorg-edgers show here how to build and install a new X.org driver.
4. The xorg-edgers recommend you do your driver testing on a Live CD (USB stick), so your system is unchanged. For applications, you can just revert to the distribution package, for example by purging (uninstalling and removing configuration files) the custom package, and then reinstalling the ordinary one. But using a Live USB stick is much easier.
5. SVN is Apache Subversion, a source code versioning and revision control system.
   Many Linux project nowadays have moved to Git. It is a distributed versioning and revision control system.
   Some projects still use CVS.
   Note that for occasional development, you only need to be able to download (check out) the sources with one of the above. To get the fix or change accepted upstream, follow the project's coding conventions and patch submission information, create a patch (creating an unified diff using diff which then can be applied with patch), prepend the necessary bits to it (description, developer info), and submit to the project mailing list.
   For doing a lot of work on one software project the version control helps a lot.

Hope this helps.

2 members found this post helpful.

I humbly suggest that perhaps you are not yet receiving a warm reception because your apparent level of background knowledge (e.g. "what is SVN?") might leave them a little skeptical.

Mind you, I'm not passing judgment here; not at all. What I'm saying is that these are first impressions. As they say, "first, you gotta get past the gatekeepers."

Perseverance and persistence, coupled with a lot of humility, might be the key here. First, you need to be sure that you are aware, not only of how to solve the problem at hand, but also how it would integrate into the (KDE...) project and clearly benefit that project. Then, consider how you can portray that level-of-knowledge to a perfect stranger. Then, on a much more pure-political level, you must persuade another engineer whom you do not yet know that they really should answer the phone when you call. (Remember, that phone rings all the time ... and much of the time it's not worth answering. As an engineer yourself, you know how that is ...)

I hope that you might find these suggestions useful. Good luck.