I hate scripts and script languages!

Ubuntu 9.04

One of the big strengths of Linux is its open nature and the capabilities to customize everything to your personal needs and taste. Most of the times it requires a bit of learning, but other times it is a blessing to be able to create the needed tool yourself knowing that probably you are alone with your weird requirement anyway :-)

One way to make tasks less taxing and more convenient for yourself in Linux is to create scripts which do the tedious jobs for you. It is well known that in stark contrast to the Windows world, where the user interface of an app you see is the whole app, in Linux many apps you are using in the graphical desktop are actually only shells and the real work is done by other, command line apps. One of the better examples of this kind of shell is K3B, the KDE's CD and DVD burning application, which uses command line utilities such as cdrdao, wodim, growisofs, etc. to do all the dirty work.

This also means that you can use these same command line utilities to do that work directly without even launching the GUI or you can also create your own GUI if you prefer it that way. One big helper in creating scripts with better usability has been the kdialog command, giving a nice graphical touch.

During my time with Linux I have created a lot of scripts for various things I do. Since these scripts have been part of my activities for a number of years already, many having seen several revisions becoming more and more robust, I had no choice but to bring them all over to Ubuntu now that I'm using it. And this brings me to the point of this post - I hate scripts and script languages!

Though there are other bad traits with the scripts such as the lack of strong typing of variables, the most I hate scripts for their loose bindings. At its simplest a script -- as opposed to a compiled language program -- is a list of commands to be run in sequence.

But what happens if one of the commands is not installed and hence unavailable? Or if the command is of the wrong version and does not have the behavior you are using in your script? Or if the command itself depends on your environment and simply works differently? What if the command expects a file or directory to be at one place but in your OS they have been moved or installed in a different location? And since the UNIX doctrine specifies text to be the default data transmission medium, the commands become dependent on your current charset - is your $LANG set to UTF-8 or simply ISO-8859-1 or perhaps even ASCII instead?

Now, in case of a compiled program (unless it too uses external commands which is very unlikely), it should run just fine under different conditions (my experience here comes from years of Pascal and Delphi programming).
But in case of a script, you are most probably busted! Unless of course you test for every possible thing that can go wrong, but in such case you have probably spent 80% of time to write 80% of code that does not do what you wanted to do with your script in the first place. And the main power of the script is meant to be the speed and simplicity of doing what you want to do!

After my move from openSUSE to Ubuntu, I have stumbled upon this script nuisance several times already. The list of either direct or indirect problems encountered so far:

1. The regular expression [a-z] does not cover all of the alphabet if $LANG is set to et_EE.UTF-8 (as I've written before).


2. The KDE4 version of kdialog does not work with keyboard anymore (as I've also written before).


3. Ubuntu includes version 6.10 of the GNU's cut utility (used to cut chars away from a line of text) which does not work in UTF-8 space - special characters are counted as two. The solution is to get at least version of 6.11, which already supports UTF-8.


4. The KDE4 version of kfmclient (K File Manager) has a reduced set of commands. While previous KDE3.5 version could be used in scripts as the main file manipulation tool (coping, moving, renaming, etc.) the current version can only be used to open Konqueror browser windows. The new tool for file manipulation is kioclient and there's no backward compatibility - you have to change your scripts if you wish to port them to KDE4!

The fortunate thing is that KDE4 is installed directly into /usr, while KDE3 was always installed into /opt/kde3. So you can always install the KDE3.5 environment and point your $PATH first to /opt/kde3 to pick up the KDE3 version first. If for any reason you need to run KDE4 version, just use the full path, for example /usr/bin/konqueror.

Thats it for today.

A better way to stop ComboBox from resizing itself automatically...

Adobe Flex 3

This is an update to my earlier post about mx:ComboBox which, if set to a percentage width, will by default always take the width of the widest line it contains, widening possibly its container and/or changing the container to be scrollable.

The solution I suggested earlier was not enough for example in case the ComboBox was on a panel which was not visible when it was created. Now I am using a different solution.

Basically you extend the ComboBox and override the protected measure() method to cancel out the setting of minimum width set by the original code which is the cause the ComboBox will force its width upon its container.

The following code has some more changes, like resizing the dropdown list to the width of the longest line it will display and also refusing even programmatic focusing when either disabled or hidden.

Did you know, that if the focus already is on the standard ComboBox, then disabling or even hiding it does not block the keyboard input? For example, the [Down] and [Up] keys still change the items within the invisible ComboBox with all the corresponding events triggering, and [CTRL-Down] will still open the dropdown list even though the ComboBox itself is hidden and disabled?

public class ComboBoxEx extends ComboBox
{
   private var initDone:Boolean;
   public var preferredDropdownWidth:Number;

   public function ComboBoxEx()
   {
      super();
      this.preferredDropdownWidth = NaN;
      this.initDone = false;

      this.addEventListener("dropdownWidthChanged",
         function(event:Event):void { if (!initDone) preferredDropdownWidth = event.target.dropdownWidth; });

      this.addEventListener(FlexEvent.INITIALIZE,
         function(event:Event):void { initDone = true; });

   }

   /** A property indicating if the combobox should resize itself to the width of its contents */
   [Inspectable(category="General", enumeration="true,false", defaultValue="false")]
   public var resizeWidthToContent:Boolean = false;

   /**
    * A property indicating if the dropdown of the combobox should resize its width to the width of the longest
    * label within the combobox'es data, though never below the width of the combobox itself.
    * NOTE! that if you leave this property to its default value of true then the property dropdownWidth
    * will not be respected if it happens to be smaller than the width of the longest label in the combobox.
    */
   [Inspectable(category="General, enumeration="true,false", defaultValue="false")]
   public var resizeDropdownWidthToContent:Boolean = true;

   /**
    *  @private
    */
   override protected function keyDownHandler(event:KeyboardEvent):void
   {
      // Handle keyboard only if we are enabled and visible!
      if (super.enabled && super.visible)
      super.keyDownHandler(event);
   }

   /**
    *  @private
    */
   override public function setFocus():void
   {
      // Take focus only if we are enabled and visible!
      if (super.enabled && super.visible)
      super.setFocus();
   }

   /**
    * The super method determines the measuredWidth and measuredHeight
    * properties of the control.
    * This version will reset the measuredWidth property to the value of
    * UIComponent.DEFAULT_MEASURED_WIDTH unless the resizeWidthToContent
    * property is set.
    * @see mx.core.ComboBase#measure()
    */
   override protected function measure():void
   {
      super.measure();
      if (!this.resizeWidthToContent) measuredMinWidth = DEFAULT_MEASURED_MIN_WIDTH;
   }

   override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
   {
      super.updateDisplayList(unscaledWidth, unscaledHeight);
      if (this.resizeDropdownWidthToContent && isNaN(this.preferredDropdownWidth))
      {
         var width:Number = getContentMaxWidth().width + getStyle("arrowButtonWidth");
         this.dropdownWidth = Math.max(this.width, width);
      }
   }

   public function getContentMaxWidth():Object
   {
      return calculatePreferredSizeFromData(this.collection.length);
   }

}

I also opened a bug about it.

Do not use your own language in Ubuntu!

Ubuntu 9.04

For crying out loud, I just spent a whole evening trying to figure out why the Gnome's Sensor Applet, which docks to the panel, does not work correctly and shows an error "Error compiling URL regex" instead of CPU core temperatures ?!?

The reason was simple - the function libsensors_plugin_init() within libsensors-plugin.c used regex which included [a-z0-9] in it and since in the alphabet of the Estonian language the letter "z" comes right after letter "s", any letters following them ("tuvxyz") will be excluded with the [a-z] regex. This included the "T" in "Core 0 Temp", so there you have it - "Error compiling URL regex" !

Aw gawd, I thought we are over this stupidity, but apparently not. Nobody probably knows the extent of this [a-z] bug and all the languages which are affected by it...

So the bottom line is:
Do not use your own language as the UI language if you want a working system!!!