Sunday, March 29, 2009

Microsoft's Guide to Windows Form... WTF?

I have just read this (for the first time): http://msdn.microsoft.com/en-us/library/ms229597(loband).aspx

This is the first article in the series of ones created by MS to help developer get started with Windows Form.

The last code snippet says:
using System;
using System.ComponentModel;
using System.Drawing;
using System.Windows.Forms;

namespace FormWithButton
{
public class Form1 : Form
{
public Button button1;
public Form1()
{
button1 = new Button();
button1.Size = new Size(40, 40);
button1.Location = new Point(30, 30);
button1.Text = "Click me";
this.Controls.Add(button1);
button1.Click += new EventHandler(button1_Click);
}
private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show("Hello World");
}
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.Run(new Form1());
}
}
}

If you notice the way the button size and location are specified, you may find it too bad.

Even for the purpose of simplifying the code in a getting started guide, they should not do that way.

WTF? At the very first step to Windows Form, Microsoft leads their developers to the most stupid mistake that any UI developer should avoid.

Wednesday, March 04, 2009

xvnkb for Fedora 10 users

I have just dumped scim-unikey in favor of the old xvnkb. This time I did a plain installation using the traditional ./configure; make; sudo make install for xvnkb from the 0.2.9a source package.

It's normal that after installing, my dear Gimp stopped working. xvnkb and Gimp seem not to play well together and the reason may be that some of the system calls which were overrided by xvnkb preload so don't work with Gimp and cause it to crash.

As noted by Tinh in the installation of xvnkb for Arch, the workaround is to disable xvnkb.so overriding in case of launching Gimp.

The method to disable overriding provided by Tinh does not work in the case that xvnkb is installed using make install. This is simply because the installation script actively disabled the preloading method using env variable. Instead, it created its own entry in the /etc/ld.so.preload for loading its so. With this method, temporarily emptying the LD_PRELOAD variable does not prevent the system to preload the xvnkb.so.

The workaround's workaround is to roll back into using the environment variable based preloading method.

To do this, you have to first remove any xvnkb related entry in the /etc/ld.so.preload file and then put this in a file named xvnkb.sh in the /etc/profile.d
export LD_PRELOAD=/lib/xvnkb.so.0.2.9a
To fix the Gimp problem, in your root terminal, do this:
# cp /usr/bin/gimp-2.6 /usr/bin/gimp-2.6-orig
Create a text file at /usr/bin/gimp-2.6 and put this into that file
#!/bin/sh

export LD_PRELOAD=""
gimp-2.6-orig $1
Go back to your root terminal, add the execution permission to the file
# chmod +x /usr/bin/gimp-2.6
Reboot your box and both xvnkb and Gimp will work (but not together, unfortunately!)