Kyum graphical frontend for Yum on KDE with screenshots

While installing Yum on openSUSE I discovered there was graphical frontend to Yum for KDE called KYum, so I installed that as well. This post has some screenshots of KYum to show it working in action. After starting up, KYum looks like in the screenshot below. In this example I have clicked the “List Updates” …

Read more

Create application shortcuts with Google Chrome

Google’s Chrome web browser lets you create "application shortcuts" for web pages. These are shortcuts on your desktop, start menu or quick launch which open Google Chrome at that web location. The search bar, options and tabs are not present when running a web page as an application and the website’s favicon is used as the application icon.

Change Adobe Photoshop Filename Compatibility Options

Adobe Photoshop’s "Save for Web" function will truncate filenames to 31 characters by default to (apparantly) allow for compatibility with Mac OS 9 browsers. The dialog box which gives the warning about the filename truncation tells you to edit the output settings but it isn’t that clear where to go to actually change the filename compatibility options. This post looks at how to do this.

New_Face failed error when using Mplayer

After upgrading from openSUSE 10.2 to openSUSE 10.3 I got the error message New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf) when starting up MPlayer to watch video files. MPlayer would run fine and show the video and play sound ok, but the on screen display would fail to display anything; the subfont.ttf it was trying to find is what was used for the on screen display.

New_Face failed. Maybe the font path is wrong.

The error message that was displayed when starting up MPlayer.

no on screen display

No on screen display text showing.

I can only guess that the compiled in settings for MPlayer had changed with this version on openSUSE, or it had done something to the configuration files or font files during the upgrade which caused this issue.

After a quick search for the above error, and then some messing around with font and configuration files, I managed to work out that MPlayer checks a number of locations to determine which font to use, in the following preference order:

  • user defined configuration file: ~/.mplayer/config
  • common system configuration file: /etc/mplayer/mplayer.conf
  • user defined font file, or symbolic link: ~/.mplayer/subfont.ttf
  • system defined font file, or symbolic link: /usr/share/mplayer/subfont.ttf

The exact location of the system configuration files will vary depending on your Linux distribution; for example /usr/share/mplayer above may instead be at /usr/local/share/mplayer. Doing locate mplayer.conf and locate share/mplayer from the command line should help you to find them.

To find the TTF fonts on your system, do locate .ttf and you’ll be returned with a list of files found that have .ttf in them, similar to the following extract:

/usr/share/fonts/truetype/albw.ttf
 /usr/share/fonts/truetype/albwb.ttf
 /usr/share/fonts/truetype/albwbi.ttf
 /usr/share/fonts/truetype/albwi.ttf
 /usr/share/fonts/truetype/andalemo.ttf
 /usr/share/fonts/truetype/andybol_.ttf
 /usr/share/fonts/truetype/andyreg_.ttf
 /usr/share/fonts/truetype/ansbi___.ttf
 /usr/share/fonts/truetype/ansb____.ttf
 /usr/share/fonts/truetype/ansi____.ttf
 /usr/share/fonts/truetype/ans_____.ttf
 /usr/share/fonts/truetype/arblwgl.ttf
 /usr/share/fonts/truetype/arial.ttf
 /usr/share/fonts/truetype/arialbd.ttf
 /usr/share/fonts/truetype/arialbi.ttf
 /usr/share/fonts/truetype/ariali.ttf
 /usr/share/fonts/truetype/ariblk.ttf
 

It’s then just a matter of selecting which font to use, and adding the following line(s) to the appropriate configuration file:


font=/usr/share/fonts/truetype/arial.ttf
subfont-text-scale=2.5

Note that’s it’s possible to change the size of the font in the on screen display using the “subfont-text-scale” property as show in the above example.

If you instead prefer to use a symbolic link to the TTF file, although I would recommend you use the configuration files instead as you then also have control over the font size, you would do this, substituting the correct paths:


ln -s /usr/share/fonts/truetype/arial.ttf ~/.mplayer/subfont.ttf
OR
sudo ln -s /usr/share/fonts/truetype/arial.ttf /usr/share/mplayer/subfont.ttf

the problem is fixed

The problem is fixed and the on screen display text is now showing.

Please note: if you are using GMPlayer (the GUI version of MPlayer) then you don’t need to resort to editing text files or creating symbolic links. If you right-click the player and select “Preferences” and then select the “Font” tab, you can set the font and scale there.

Java error executing Zend Studio

After I unwittingly upgraded from openSUSE 10.2 to openSUSE 10.3, I wasn’t able to run Zend Studio 5.5.0. I would click the icon to start it up and nothing would happen; even the splash screen would not appear. I opened up a command prompt and ran Zend Studio from there, assuming I might get some sort of error output. Sure enough:




$ /path/to/ZendStudio-5.5.0/bin/ZDE
java: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted

Hmm, that looks like some sort of Java error to me. Given that I’d just done a big update to my operating system I thought that maybe Java had become screwed up or something, so the first thing I did was to reinstall it (I’d had some success in removing and then reinstalling some of the corrupted software from my upgrade). That didn’t make any difference though, and I still got the same error.

So I plugged the error message into Google and first result was this page on the Sun Developer Network site. I didn’t actually bother reading the text on the page, just did a Ctrl+F to find the error message on the page, which happened to be in the user submitted comments under the bug report. I scrolled down, scanning the posts for any useful information until I spotted a post that said: “I have the same problem with OpenSuSE 10.3. The sed-workaround works for me.”

Aha! so a quick search on the page for “sed” and I spotted this post:


I worked with jcristau and christoph4 via IRC on #debian-x, and we managed to
track down the problem with broken locking in Sun Java 1.5 and 1.6.It only
occurs if Java finds the Xinerama extension, at which point it does something
broken with locking and triggers the assertion.If Java never finds the
Xinerama extension, it doesn't trigger the assertion for broken locking.

The following workarounds address this problem:

For sun-java5-bin:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/xawt/libmawt.so

For sun-java6-bin:
sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so

The same fix (applied to the appropriate file) might work for other
proprietary JDKs.

I ran

sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/xawt/libmawt.so

as the root user but got the following error message:


sed: can't read /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/xawt/libmawt.so

I used “find” the locate the actual location of the file:


find /usr/lib64/jvm -name "libmawt.so"
/usr/lib64/jvm/java-1.5.0-sun-1.5.0_update8/jre/lib/amd64/headless/libmawt.so
/usr/lib64/jvm/java-1.5.0-sun-1.5.0_update8/jre/lib/amd64/motif21/libmawt.so
/usr/lib64/jvm/java-1.5.0-sun-1.5.0_update8/jre/lib/amd64/xawt/libmawt.so

and then ran the sed command again like so:


sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib64/jvm/java-1.5.0-sun-1.5.0_update8/jre/lib/amd64/xawt/libmawt.so

However, Zend Studio still wouldn’t run, exiting with the same java: xcb_xlib.c:52: xcb_xlib_unlock: Assertion `c->xlib.lock' failed error message. I figured Zend must have its own copies of those Java files so another find on the directory Zend Studio is installed to turned up with:


$ find /path/to/ZendStudio-5.5.0 -name "libmawt.so"
/path/to/ZendStudio-5.5.0/jre/lib/i386/xawt/libmawt.so
/path/to/ZendStudio-5.5.0/jre/lib/i386/motif21/libmawt.so
/path/to/ZendStudio-5.5.0/jre/lib/i386/headless/libmawt.so

So I ran the sed command again on the Zend Studio version of the file:


sed -i 's/XINERAMA/FAKEEXTN/g' /path/to/ZendStudio-5.5.0/jre/lib/i386/xawt/libmawt.so

and this time Zend Studio was able to run. Yay!

How to disable Javascript in Mozilla Firefox

Forms on websites are typically validated using Javascript on the client side to prevent additional round trips to the server if a form hasn’t been completed correctly, and are then also validated on the server side. When testing a website you need to be able to test both so need to disable Javascript in your web browser to test the server side validation. This post looks at how to disable Javascript in the Mozilla Firefox web browser. The specific version the screenshots come from are Firefox 3 but it should be the same for earlier versions.