KDE for Windows

KDE 4.1 is here, and windows.kde.org packed it for Win32 already. As long as there are lots of useful apps in KDE without good win32 alternatives - I installed it on my working XP machine.

While Amarok is still in deep alpha - I couldn't start it. But there are two apps I can't live without - KWrite and Kompare. Both of them have great user interface, and gives you all advanced possibilities you can imagine. There is no other free editor to support about 90 different source file types and full encoding support, with possibility to open file with one encoding and to save with any other. There is no good file comparition program with such pretty and usable interface as Kompare. If you are interested - give it a try!

I am still waiting for Krusader and Okular, but my life under windows is already much simpler.

Security circus

In big outsourcing offices there are lots of security policies, and most of them are stupid enough. Don't you think so?

On my current job there is policy to change passwords every 3 weeks. What for? My first password was something like "R00mpel$htit$hen", while all the next password are "Anykey1", "Anykey2", ..., "AnykeyN". Same for all guys in my team. So, is office security much stronger now?

Java5 forever or Codename: No Future

Java6 exists almost two years now, and Java5 "is in its Java Technology End of Life (EOL) transition period". While I admire people, using top versions of Sun's Java, there are lots of folks, who are still using Java5. All of them have different reasons: someone just don't want to bother saying "Why should I?", someone have some strange compatibility or porting problems. Someone saying about business, about cost of migrating from Java5 to Java6.

But how long your project will exist on Java5? Year or two? You spent your money on your project, do you really want to join it's lifetime with Java5 lifetime?

Let me explain. You have project, you have N services and X users. If your organization has no evolution - everything is just fine. But if your project grows - you have N = N + 1 services and X = X + 50 users each half-year. Once your current hardware will not be enough, you will move to better hardware. On better hardware you will have new operating system that supports all your hardware (for example, Windows 2003 Server supports only 4 CPUs/CPU kernels). And what if there will be no Java5 for that operating system? Sun is not supporting Java3, Java4 and soon Java5 anymore, who will care about your problems and your needs? Red Hat? Or Microsoft? Currently, there is even no possibility to download Java3 directly from Sun, or there is no Java4 for x86_64 platform. Do you want to make your business on zombie products?

Sun gives you the best platform of our times. Sun gives you standards, public APIs, open and flexible platform. Sun gives you own implementation of it's platform, saying there are lots of them around. Sun also guarantee backward compatibility (Java4-Java5 is another step, I am talking only about Java5-Java6 now), and only possible compatibility problem - usage of sun.** API. But even here Sun gave you compiler warning: "sun.** is Sun proprietary API and may be removed in a future release", and it's some king of mental retardation to ignore warnings like this.

So, as for me - if you can't move from Java5 to Java6 - your project is dead, and you is guilty in its death, no matter how long will it take to make it smell like old corpse.

KTorrent vs Anti-Cheater

After updating to SUSE 11.0 torrent client for KDE updated from KTorrent 2.2.1 to KTorrent 3.0.x. But on my favourite tracker I receive "Anti-Cheater: You cannot use this agent" as status message while using KTorrent 3. I installed KTorrent 3.1 - and get same message. But after installing back 2.2.x - everything works fine. So, problem is User-Agent string. It is not very hard to search over KTorrent sources and modify it a bit to change User-Agent string. I already mentioned great tutorial about rpm building, and this time it saved me again...

Get the source
Download the src.rpm file and unpack it. I am using mc to navigate into src.rpm and copy all files from there to /home/to_build/src/ktorrent folder.

Diff to change user-agent
You can add diff to any spec file to apply it before build. It is much better than modify and pack sources back. So, here is my diff to change KTorrent 3.1 User-Agent string from "KTorrent + version" to plain "KTorrent". Now just save it in same folder ("/home/to_build/src/ktorrent" for me).

Modify spec file
Now only few modifications to spec file and time to start building:
Add this lines:

Patch10: user-agent.diff
%patch10

It is easy enough to find where to insert it, there are already few patches applyed.

And now, to enable blocked by SUSE trackers, comment this two lines:

#Patch2: remove-links.diff
#%patch2

Now just build and use your favourite torrent-client with your favourite tracker!

SUSE 11.0 handmade

SUSE 11.0 released about a week ago. As few previous versions, there is lack of proprietary multimedia formats support. And there is few ways to resolve it. First, most common way - to add packman repository and install everything from there, and to find other repositories for freetype2 and few other packages. But I don't like this way. SUSE team did a great job with packages and integration, downloaded from other sources packages rarely have this level of integration. My way - to take official SUSE src.rpm packages from official source repositories, and build it with SUSE build tools.

Preparing:
There is a great tutorial about "build", it will introduce build procedure for you. It will prepare you for reading this article.
Also, there is some packages from internet repository you will need. I don't know why aren't they on DVD. You can store them to folder of provided packages, "/home/to_build/provided" for me. I got them from x86_64 repository, and videolan repository for libmad and libdvdcss.

avahi-lang-0.6.22-68.1.x86_64.rpm
flac-devel-1.2.1-43.1.x86_64.rpm
gconf2-lang-2.22.0-28.1.x86_64.rpm
gnome-vfs2-lang-2.22.0-33.1.x86_64.rpm
gstreamer-0_10-lang-0.10.19-16.1.x86_64.rpm
gstreamer-0_10-plugins-base-lang-0.10.19-24.1.x86_64.rpm
libbonobo-lang-2.22.0-21.1.x86_64.rpm
libcdio++0-0.80-3.1.x86_64.rpm
libcdio-devel-0.80-3.1.x86_64.rpm
libdvdcss-1.2.9-5.1.x86_64.rpm
libgnutls-devel-2.2.2-17.1.x86_64.rpm
libiso9660-5-0.80-3.1.x86_64.rpm
libmad-0.15.1b-5.1.x86_64.rpm
libmad-devel-0.15.1b-5.1.x86_64.rpm
libtheora-devel-1.0.beta2-3.1.x86_64.rpm
libudf0-0.80-3.1.x86_64.rpm
speex-devel-1.1.99.3-28.1.x86_64.rpm
vcdimager-0.7.23-132.1.x86_64.rpm
vcdimager-devel-0.7.23-132.1.x86_64.rpm

Step One - xine
The most important multimedia part of SUSE distro - xine engine. Let's build it first.
1. Download xine-lib-1.1.12-8.1.src.rpm from SUSE repositories and unpack it to some (target) folder.
2. Remove xine-lib-1.1.12-crippled.tar.bz2 from target folder.
3. Download xine-lib-1.1.12.tar.bz2 from official sourceforge website and save it to target folder.
4. Open xine-lib.spec with your favourite editor.
5. Change line like this:
from "%define BUILD_XINE %{?_with_internal:2}%{!?_with_internal:%build_xine_default}" to "%define BUILD_XINE 2".
6. Set Release to "Release: 8.1.1" - it will with pleasure override already installed xine.
7. Modify source declaration from crippled:
from:

Source: xine-lib-%version-crippled.tar.bz2
%if 0
Source: xine-lib-%version.tar.bz2
%endif

to:

Source: xine-lib-%version.tar.bz2

8. Find and comment each of lines to let sources be uncrippled:

Source99: precheckin_cripple_tarball.sh
Patch70: xine-lib-crippled-LOCAL.diff
%patch70

9. Also, change all "mad" and "mad-devel" dependencies to "libmad" and "libmad-devel".
10. just build it:
build --root /home/to_build/root --rpms /home/to_build/provided xine-lib.spec
11. Take your packages from "/home/to_build/root/usr/src/packages/RPMS/".

Step Two - Kaffeine
Kaffeine is best front-end for xine ever-made. Let's build it with DVD support!
1. Download kaffeine-0.8.6-54.1.src.rpm and unpack it.
2. Comment each of this lines:

Patch0: %name.diff
Patch2: messagebox-dvd.diff

3. Build it. I got small problem with some locale files, so you can just add locale files after icons packaging:
from:

/opt/kde3/share/appl*/*/*
/opt/kde3/share/apps/kaffeine
/opt/kde3/share/apps/konqueror
/opt/kde3/share/apps/profiles
/opt/kde3/share/icons/*
/opt/kde3/share/mimelnk/*/*.desktop

to:

/opt/kde3/share/appl*/*/*
/opt/kde3/share/apps/kaffeine
/opt/kde3/share/apps/konqueror
/opt/kde3/share/apps/profiles
/opt/kde3/share/icons/*
/opt/kde3/share/locale/*/*/*
/opt/kde3/share/mimelnk/*/*.desktop

Step Three - FreeType2
There is no subpixel font smoothing in SUSE, so it will be useful for LCD owners.
1. Download freetype2-2.3.5-62.1.src.rpm from SUSE repository and unpack it, for example into "/home/to_build/src/freetype".
2. Download full FreeType2 from official website into same folder ("/home/to_build/src/freetype"), replacing old one.
3. Change two blocks:
from

Source0: http://download.savannah.gnu.org/releases/freetype/freetype-%{version}.tar.bz2
Source1: http://download.savannah.gnu.org/releases/freetype/freetype-doc-%{version}.tar.bz2

to

Source0: freetype-%{version}.tar.bz2
Source1: freetype-doc-%{version}.tar.bz2

and from

%define enable_subpixel_rendering 0%{?opensuse_bs}

to

%define enable_subpixel_rendering 1

4. Just build it and install packages from same folder - "/home/to_build/root/usr/src/packages/RPMS/"

That is all! Now you have your SUSE good as new, without less integrated third-party packages and without crippled multimedia. It's time to install win32 codecs from packman and libdvdcss from videolan before first kaffeine launch, install amarok-xine and remove buggy amarok-yauap plugin.

SUSE 11.0 first impression

Yesterday I have installed new SUSE 11.0 linux at home. Impressions are very ambiguous...

1. Package manager works great! Starting from SUSE 10.0 it was slower and slower, scanning repositories for minutes, than hours, checking depencencies, updating indexes and doing lots of interesting, but totally unusable staff. New package manager in 11.0 is faster than light! Adding huge repositories takes less than second, depencency checks are done faster than you can even notice!
Second great improvement for package manager - much better dependencies lists. I hate mono, banshee and other dotnet staff, I totally disregard it. But in SUSE 10.1 and 10.2 I HAD TO install mono just because of some yast pattern. That time I even downloaded few distros to look for SUSE replacement. Why, the Hell, I need software patterns for package manager if there are plain dependencies with straight structure?! But now I am totally happy - no mono, no beagle, no banshee, no gtk-sharps and other crap in my fresh system.

2. Older SUSEs with first boot after installing loaded yast to configure different devices, network and graphics. This did not. It was very hard to read fonts with default screen resolution (1280x1024), while installer worked with 1024x768.

3. Selection of KDE version is very hard. KDE 4.0.4 is very interesting, giving great fast new desktop experience. While there are some leaks: 1) I am not extreme enough to use PIM from unstable 4.1 sources; 2) Alt+Tab hangs sometimes when you have few windows from other users; 3) there is no printer configuration in KDE control center now, and YaST module changed from 10.2 and can't configure it for some reason... So, clicking few hours in KDE4 is great, but I'll wait a month for 4.1 to arrive.

4. It is hard to choose all programs from one of KDE desktops. KTorrent is KDE4 by default, KGet in KDE4 is totally great. But Dolphin will never move Krusader away, K3b and Amarok still not ported to KDE4, Gwenview of KDE4 differs too much from original KDE3 version, and older is much more usable.

No horses for Nurgle forces

There are four major Chaos Gods in Warhammer. Each of them has it's own main idea. And each of them differs so much from others, that it's hard enough to put all of them to one army. But the most separated from others is Nurgle.

Khorne means rage, blood. It is not hard to give horses or other mounts to bloody berserkers. Tzeentch is hope - he is bad only because he is opposite to imperium or Emperor, so he can do everything. Slaanesh is pleasure - nothing evil, just pleasure. But Nurgle is decay. How many animals will accept decay? How many possibilities decay have? Medieval horses were scared by smell of camels, what can we say about Nurgle warriors? Griffins, dragons - who will take decayed champion close to himself? The only way to get horses or other mounts for Nurgle warriors - put decay deep in their minds and bodies. Small job for major Chaos God, but almost impossible for his cults. Only humanity is decayed enough to accept Nurgle without compromises. This guys far from "grean peace", in spite of being green to.

LookAndFeel chooser

You will not dispute that modern desktop application needs some theming, right? And, being Swing developer, few times you tried to solve this problem, didn't you?..

I have solution now: JLAFChooser.
Now, you can just put JLAFChooser component into your setting dialog, and it will make LookAndFeel chosing possible in runtime. Now you have no need to hardcode all the LookAndFeels you know into your classes or XML files, and user can just download few LookAndFeels and put it somewhere in classpath to make it available to JVM.

It has two main variants: when Apply is allowed and when not.

When Apply is allowed your user can choose something from list and check it at once, and may be choose something else.



When Apply IS NOT allowed you can just show list of possible LookAndFeels, and save somewhere to preferences user selection, to apply it next startup.


Usage is similar to JColorChooser, with few extensions - you can get LookAndFeel instance, it's name or it's class name. Methods to apply and restore LookAndFeel are public, you may use them for your controls.

PS: feel free to mail me for suggestions, bugs, or just to talk about Java, Swing, religion, fantasy or anything...