I'll Soar

Finally got around to writing a gospel parody of Jason Mraz's "I'm Yours" and played it on a concert uke for fun ...

* Here are the chords and lyrics.

Enjoy.

jQuery's show() function does not work on my BlackBerry ... sometimes :-)

Sometimes the show function in jQuery does not work in the (4.6.1) BlackBerry browser. Below is a detailed explanation the problem, followed by a solution showing how to fix this, and then an educated guess at the reason for the problem:

1) The problem may occur if you have something like the following javascript code in your web page:

<script src="js/jquery-1.4.1.min.js" ></script>
<script>
$(document).ready( function() {
   $('div.features').hide();           // hide all divs of class="features"
   $('div.features').first().show();   // show the first div of class "features"
});
</script>
<script>
function reveal(featureId) {
   $('div.features').hide();      // hide all divs of class="features"
   $('div#' + featureId).show();  // show the div with id=featureId
}
</script>
...
<select onchange="reveal(this.options[selectedIndex].value)" > 
   <option value="feature1" >BB Browser feature 1</option> 
   <option value="feature2" >BB Browser feature 2</option> 
   <option value="feature3" >BB Browser feature 3</option>
</select>
<div id="feature1" class="features">BB Browser feature 1</div>
<div id="feature2" class="features">BB Browser feature 2</div>
<div id="feature3" class="features">BB Browser feature 3</div>
...

Now if the "reveal" function is called using the <select onchange="reveal(...)"> as shown above, the call to the show() function will sometimes not have the desired effect of changing the display style of the div from "none" to "block".

2) My suggested solution or fix for this:
Use .css("display", "block") instead of .show()

3) Why is this happening only on my BlackBerry?
It appears that on the BlackBerry browser (at least the version noted) there is a race condition that causes this as follows:

a) Sometimes jQuery's data cache of the display values is set before the $(document).ready function is called, and so the styles are all cached as "display:block" which results in the expected behavior.

b) but sometimes jQuery's data cache of the display values occurs after the $(document).ready function is called, and so the styles are cached as "display:none" (except for the first one in this example). Which results in only being able to "reveal" the first feature ... jQuery's show() function is in fact getting called in any case. It is simply setting the display style to the cached value which is "none" in this case.

c) It appears that this issue starts occurring only after returning to the page a few times, or by returning to the page using a bookmark. You can try it here with your BlackBerry browser.

There may be some magic jQuery function that could be called in $(document).ready function before the hide(s) take place to make sure that jQuery's data cache is populated with the desired values first, but I'll leave that and any other errors in this discription of the issue to the jQuery experts in the comments below :-)

Hope that helps.

NOTE: This was discovered while testing with a BlackBerry 8350i running v4.6.1.204 of the BlackBerry OS using the jQuery.fn.show function with javascript turned on, of course.
NOTE: This was discovered using jquery-1.4.1.min.js
NOTE: Could not reproduce this issue using a BlackBerry 9700 running v5.0.0.330 of the BlackBerry OS ... it just works fine.

The good and the bad ...

How many trashy youtube videos get advertised for us to see? How many comments are made about each and every detail of those videos? Now let's examine the other edge of the sword of truth. How many good things can you find in a video like this ...



Discuss.

Error getting repository data for rawhide, repository not found

If you get this error, do not worry. This issue is "normal" with Fedora. No other distro that I am aware of changes your default repositories without letting you know, except Fedora. So that is the problem. Yum has decided to replace your /etc/yum.repos.d/fedora-rawhide.repo file with NOTHING.

So you can issue the following command:

# cp /etc/yum.repos.d/fedora-rawhide.repo.rpmnew /etc/yum.repos.d/fedora-rawhide.repo

And you may be back to normal.

I say you "may" be back to normal, because, in my case, there is still an issue. I am behind a "transparent" proxy and the folks who update the fedora-rawhide.repo file love to use https. Well, this causes me to get the following error: "Cannot retrieve metalink for repository: rawhide. Please verify its path and try again". If you simply edit the fedora-rawhide.repo file and change the https to http, updates work fine.

It appears that there is some software downstream from the fedora-rawhide.repo parsing that has problems conducting https through our "transparent" proxy ... imagine that.

Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory

Do not worry. Here is the solution to your problem:

Answer: Just try specifying a video output driver on the command line when you launch mplayer like this:

mplayer -vo xv video.wmv

You can get a list of "Available video output drivers" with the command "mplayer -vo help".

Details, if you are interested:

The problem is that the selected (or default) video output driver was vdpau, and no one working on the mplayer packages and software cares enough about having the software package work with your configuration of hardware and software. But do not worry, you are now blessed with this answer, and the video output driver can be specified on the command line (e.g. -vo xv).

The order of configuration options that mplayer will scrawl before it finally decides to (only) try the (missing) vdpau driver is not so obvious, but I think it roughly goes like this:

1. Check the ~/.mplayer/config for the (user specific) default video output driver, if any
2. Then check /etc/mplayer/mplayer.conf for the (system specific) default video output driver, if any
3. Then check in the compile options that mplayer was built with for a default (build specific).

If the mplayer command you were using was compiled with the vdpau option and there are no default video output drivers specified in ~/.mplayer/config or /etc/mplayer/mplayer.conf (which is either a common occurrence or I am the only person on the planet earth who has ever had problems with a configuration option on a linux box) then it will fall back to the compiled default which in this case was vdpau.

More details, imagine that:

Another similar issue is that mplayer may work fine while gmplayer gives this same error using the same options you just tried with mplayer. Well guess what? gmplayer uses yet another config file, ~/.mplayer/gui.conf, and it will default to the last video driver specified (or defaulted to in the compile options). So again, just specify a video output driver on the command line, or put one in one of the myriad of config files mentioned here.

Hope that helps.