Visit the LQ Articles and Editorials section
Go Back > Blogs > rainbowsally
User Name


Rate this Entry

Let's Go Retro Now, Everybody's Learning How...

Posted 01-17-2012 at 01:01 AM by rainbowsally
Updated 08-06-2014 at 11:36 AM by rainbowsally (typo)

Living on the "Trailing Edge" of computer development sometimes makes a LOT of sense.

1. Kdevelop 3 vs. 4.

The kde4 version of this ide/programming editor became a bit too ambitious, I think. Spitting out one perfect plasma widgets at the click of a button. But it's unrealistic to think that an automatic plasmoid creator will lead to programming prowess and many of the old features that were in kdevelop3 are sorely missed.

I'd take the graphical regex editor over the VI mode any day. I'd take an editor that can work efficiently with simple C programs over a plasmoid template (that installs the widget in the wrong folders too. (Wrong folders for openSUSE, I dropped investigation in kubuntu when uninstalling kdevelop4 stripped my kubuntu down to bare bones due to mismatches in my installation and the DVD archives).

That new kdevelop application generates 50 megs (I kid you not) of useless junk for every "hello world" C program you write. This junk pile is in a hidden folder in your home folder and is "per session" data, meaning that these junk piles are duplicated and persistant wastes of your hard drive even when they serve no useful purpose.

Kdevelop3 was much better, despite the lack of luster. It is, in my opinion, the best ide/programming editor around to date. But it seems to no longer compile on modern systems (due to tons of minor issues that cmake-ed builds are unforgiving about) and therefor needs to be installed as a binary.

Kdevelop3 will pretty much install with only the qt3 support and kdelibs3 stuff.

Missing development files aren't critical (in fact they are to be avoided, see below) for using it as a programming editor, so you may force the installation using yast overrides or dpkg commandline switches.


This is kdevelop3 running with the regex helper menu showing.

[the image may appear oversized on a 800x600 screen. the shot was taken on a 1024x768 screen.]

The 'find in files' function is also incredibly powerful. (alt-ctrl-F)

The shot above is of a C++ parser generator application. It writes C++ code to parse text based on a bnf-like syntax the user defines. The total size of the entire package including the binary, docs, 7 demos, 15 tutorials, an optimizer, a static/dynamic linkage option and a 32-bit and a 64-bit "panic" executable (it metacompiles itself) is

3,159,282 total

Oh. And there's a makefile. :-)

That's 3 megs of actual source code, nothing hidden, not 50 megs of hidden nonsense for "hello world" in C.

It doesn't have macro key (recording and playback). Neither does the kde4 version. But nedit is small and can be used for stuff the regex can't handle easily.

Here's the clickable/relocatable script that launches the ide.
# The newer kdevelop is bulky and has bad shortcut keys.  We use
# the kde3 version.

CURDIR=`dirname "$0"`
cd "$CURDIR"
#this is buggy, let's get rid of it.
rm -f "$HOME"/.kde/share/config/kdevfileselectorrc
if kdevlite -v
    kdevlite "$CURDIR"/buffalo.kdevelop
    kdevelop "$CURDIR"/buffalo.kdevelop
[Note: kdevlite (see above) was the version I created for developer evaluation. Nobody did. Forward ho! Ho ho ho!]

2. kolourpaint kde3 v. 4.

Dunno about you but my intel i915 driver sure doesn't like scaling images in the new kolourpaint, if that's even the problem.

The older kolourpaint is in the kde package 'kdegraphics3-imaging-3' (rpm, not sure which deb).

These retro packages from kde3 will also likely be needed. Exact version matches are probably not necessary. Binary compatible should do it.
These packages are organized somewhat oddly in kubuntu, so you're on your own there.


There are several ways to force installation of an app that the package managers think won't work. (I may upload a toolkit that can generate makefiles with 'revert' functionality a bit later.)

For example it's possible to extract the package to a directory tree and copy the files manually into the system as long as there's no special configuration to be done. That, after all, is what makefiles do after the files are compiled.

The most likely snags are configuration issues, which are usually solveable by installing other retro packages or libs as long as the packages you are installing are for your linux genre. And sometimes even the genre doesn't matter (but paths may be different and may require some tweeks).

Some dependencies will show up at runtime, especially if the dependency is an interpreter like perl or tcl/tk.

Others can be discovered before copying into the system by running ldd <libname> or ldd <executable> in the folder where you extracted the lib or executable. Ignore those dependencies that are included in the package, of course.

Retro *development* packages should be avoided, however, because these often include the libs with a plain un-numbered *.so name which are symlinks to the assumed default lib version such as *.so.<N> with the highest version numbered lib being the latest/default.

For example, you can have and both in the /lib folder as long as the points to the so.6 version.

*** Let's say th9is again. By installing retro *develepment* packages you risk compiling and linking against the older libs which will make the newer one invisible due to the incorrect symlink. (See above.)


The newer kolourpaint would not blow up images without losing the colors and at times even the image.

This is the older one forced, as per the methods above, into openSUSE 11.4 blowing up an icon by 800 percent with colors and image still quite recognizable.

[The image may appear oversized on 800x600 screens.]

Is life on the trailing edge risky?

Of course it is. Make tarball backups of anything that might change before you experiment unless you have a better way to restore a broken system using file lists, preferably with attributes. As root your tarballs will retain perms, symlinks as symlinks, etc. And have a rescue CD you can use to boot into a broken linux installation.

**Never assume all is lost** until you know for absolutely sure that it is.

You can almost always recover from terrible problems and you'll learn a lot as you discover how.

But there are times when even the best tools and utmost effort will not replace lost or corrupted system files so backups and a bit of familiarity with the linux terminal are the most important part of having a good experience...

Living On The Trailing Edge of computer technology.
Posted in Uncategorized
Views 346 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 09:46 AM.

Main Menu

Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration