Monthly Archives: January 2009

Jan 27 2009

Making jEdit Run Correctly on Vista

I recently got a new computer at work, running Windows Vista. I’ve had Vista on my home computer for almost a year now, and I like it; it improves on XP in many ways. The UAC hadn’t caused me any issues at home, but it’s been involved in a few problems on this new computer.

I say “involved” because the problems aren’t really the fault of UAC, but of the programs running afoul of it. We’ll use my installation of jEdit as an example.

Installing jEdit

I downloaded the Windows installer, ran the EXE, and clicked “Continue” and “Allow” to let it run as an administrator. Installation went smoothly, and the installer launched the program; so far, so good. I proceed to install a few plugins, set a few preferences, etc.; all is well. Then I reboot my computer after installing some other software…

When I try to open jEdit again, the program freezes. So I kill the javaw process and try again: same result. Try running it as an administrator: it opens just fine. What’s going on? I didn’t have any problems with it on my home computer.

Tracking Down the Bug

Now that I have the program open as an administrator, I can look at its activity log. What do I see?

Log: user.home=C:\Users\lits

C:\Users\lits isn’t my home directory, it’s C:\Users\jmbrinley. lits is the username for the IT department that initially set up the computer for me. jEdit is trying to access files in another user’s home directory, and UAC is (rightfully) preventing it.

Where does jEdit get the idea that C:\Users\lits is my home directory? It seems to be related to a six-year-old bug in Java, by which user.home does not necessarily equal the %USERPROFILE% environment variable. It might equal another user’s home directory, or the home directory of a user that no longer exists, or the former home directory of the current user. There’s no way to know. It seems I just got lucky when I installed at home.

The Workaround

You can work around this by explicitly setting user.home when you launch Java.

  1. Find the batch file jEdit made when it installed (probably at C:\Program Files\jEdit\jedit.bat).
  2. After the path to the Java executable ("C:\Windows\system32\javaw.exe" on my system), add the flag -Duser.home=%USERPROFILE% so that the whole batch file looks like: 
    @echo off
start "jEdit startup" "C:\Windows\system32\javaw.exe" -Duser.home=%USERPROFILE% -Xmx192M -jar "C:\Program Files\jEdit\jedit.jar" -reuseview %*
  3. Find any shortcuts to jEdit, and change the target to "C:\Program Files\jEdit\jedit.bat" (use the path to your batch file, if different).
  4. If you have “Open with jEdit” in your Explorer context menu, open your registry and go to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\Open with jEdit\Command. Set the default string to "C:\Program Files\jEdit\jedit.bat" "%1" (again, use the path to your batch file, if different).

jEdit should now be in working order. I’d prefer to set user.home using an environment variable, to fix it across all Java programs, but I haven’t figured out how to do that, yet. In the meantime, this workaround gets the job done.

Posted by Jonathan Brinley

Category: Coding

Tags: , , ,

2 Comments

Jan 24 2009

Pizza Crust Recipe

A while back I promised some people I’d post my pizza crust recipe, so here we go:

Ingredients

2.25 tsp. yeast
1.5 c. warm water
1 T. sugar
0.5 tsp. salt
3.5-5 c. white bread flour

Directions

  1. Mix yeast and water
  2. Add salt and sugar
  3. Slowly mix in an appropriate amount of flour (How much is appropriate? Good question… I keep adding flour until I can hold it in my hand without it sticking.)
  4. Let it rise for about 30 minutes
  5. Press, spin, etc., dough into a pizza shape
  6. Let it rise for another 10-30 minutes
  7. Brush a bit of olive oil on the outer edge of the crust (optional)
  8. Top with toppings
  9. Bake at 450°F for 20-30 minutes (or about 10-15 minutes on a pre-heated pizza stone)

Posted by Jonathan Brinley

Category: Etcetera

Tags: ,

Leave a comment

Jan 20 2009

Frozen Intertubes

Last week was cold, very cold. I took the standard precautions for my water pipes, leaving a dripping faucet overnight. Who knew, though, that those weren’t the only pipes that could freeze?

Wednesday night, as the temperature dropped, my Internet connection slowed down to an unbearable crawl. The next morning, I had no connection at all. After some trouble-shooting over the phone with Comcast, they scheduled someone to visit us on Saturday.

Mid-day on Thursday, the connection came back. I assumed that Comcast had fixed a line into the neighborhood, that all would be well. End of story.

‘Twasn’t to be. Thursday night, we lost our connection again. Friday morning, it came back.

Friday night, we lost our connection. Saturday morning, it came back.

At this point, I had a theory: packets were freezing in my intertubes. “That’s impossible,” I then told myself. “The Internet can’t just freeze like that.” Nonetheless, it fit the evidence, so I needed a reasonable explanation of how it might happen.

Here’s what I came up with: there’s a bad connection somewhere. Small bits of metal might be contracting and pulling apart from each other, making this connection even worse. When it gets cold enough, the metal contracts enough that I lose my connection entirely.

Saturday evening, the Comcast technician came. I explained what was happening, and he was just as surprised as I. He started at my modem and started looking at connections heading out of the house. After reaching the last connection in the crawl space, he saw that it might have been corroded. He replaced the hardware there, and my connection has worked since then.

Of course, it’s also been 30 degrees warmer since then, so I’m not certain that the problem happened there. But I have an Internet connection, so I’m happy. We’ll see what happens next time the temperature drops below 0.

Update (2009-01-30): Nope, not that connection. Looks like it must be one outside the house. Another Comcast technician came yesterday, but he didn’t want to haul his ladder all the way up our driveway. We’ll have to wait until this weekend to see if we can get Internet access after sunset.

Update (2009-02-01): Somebody from Comcast willing to climb a ladder finally made it out this weekend. Looks like a squirrel ate our cable line, letting water in, which was freezing at night.

Posted by Jonathan Brinley

Category: Etcetera

Tags: , , , ,

1 Comment

Jan 15 2009

IE Bug Improperly Displays Floats

Updated (2009-01-15): I finally stumbled across the answer (see below).

[Originally posted 2008-01-18] I’ve recently come to understand a bug in how Internet Explorer handles floats. I doubt this is a new discovery, but I haven’t read about it and can’t easily find it through Google. To put it simply, floated boxes should overlap non-positioned block boxes but displace inline boxes; Internet Explorer displaces both. Now that I’ve said it simply, I’ll try to say it more clearly and accurately and with pictures.

We’ll start with a pretty simple XHTML document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	<head>
		<title>IE Float Bug</title>
	</head>
	<body>
		<p id="red">red</p>
		<p id="blue">blue</p>
	</body>
</html>

Now let’s add some color and play with our p boxes, adding the following to our header:

<style type="text/css">
	p {
		margin: 0 5px 0 0;
		padding: 0;
		color: #FFFFFF;
		border: 5px solid #000000;
		text-align: center;
	}
	#red {
		background-color: #FF0000;
		width: 100px;
		height: 100px;
		line-height: 100px;
	}
	#blue {
		background-color: #0000FF;
		width: 150px;
		height: 150px;
		line-height: 150px;
	}
</style>

That should give us a page that looks like:

Flowing red and blue boxes

Now, let’s add float: left; to #red and see what happens in Firefox:

Floating red with blue, Firefox

To explain what’s going on here, #red is removed from the normal flow of the document. #blue, then, being a block box, moves to where it would be if #red were not in the document at all. The text inside of #blue, though, has to be aware (if you’ll allow this personification) of the float, because its line box has to be shortened to avoid overlapping with #red‘s margin box. This all conforms to the CSS 2.1 visual formatting model.

But look at what happens in Internet Explorer 7:

Floating red with blue, IE

Instead of just displacing the text, the entire block-level box #blue has shifted to make room for #red. This would be entirely appropriate if I had created a new block formatting context by, for example, adding overflow: hidden to #blue. But so long as #blue‘s overflow is set to its default value of visible, as it is here, we have no new block formatting context, so #red should overlap #blue.

So how do I fix this? How do I make IE render this the same way as Firefox? I would appreciate any help.

Update: The Answer

If you can avoid triggering hasLayout in IE, then #blue will behave as it should. In the example above, setting height and width on #blue both triggered it, but with a few changes, we can avoid that to get the results we want.

First, remove height and width from #blue. To be honest, height wasn’t necessary, since line-height already sets the height of the element (assuming you’ve only one line of text).

So how do we constrain the width? By setting width on body (or a div that wraps both ps, if you want to do this in the context of a real page). So give body a width of 165px(to accommodate the desired width, margin, and border or #blue).

So our final CSS looks like:

<style type="text/css">
	body {
		width: 165px;
	}
	p {
		margin: 0 5px 0 0;
		padding: 0;
		color: #FFFFFF;
		border: 5px solid #000000;
		text-align: center;
	}
	#red {
		background-color: #FF0000;
		width: 100px;
		height: 100px;
		line-height: 100px;
	}
	#blue {
		background-color: #0000FF;
		line-height: 150px;
	}
</style>

That gives us the same result in IE and Firefox.

Posted by Jonathan Brinley

Category: Coding

Tags: ,

Leave a comment

Jan 05 2009

JavaScript Capabilities by Browser

If I want statistics for the market share for various browsers, I can get them from places like Net Applications or W3Schools (with different collectors skewed in a different directions for various reasons not relevant to this post). Wikipedia has a pretty helpful roundup of the various statistics collectors.

Similarly, if I want statistics for users with JavaScript enabled/disabled, there are several sources, such as TheCounter.com and, again, W3Schools.

I’m particularly interested, though, in a combination of those two sets of statistics. What percentage of users disables JavaScript for a given browser? Are Firefox users more likely to have JavaScript disabled than Internet Explorer users? Are IE6 users more likely to have it disabled than those that have upgraded to IE7?

Do you know where I might find these statistics? If so, please let me (and the world, for that matter) know.

Posted by Jonathan Brinley

Category: Coding

Tags: ,

Leave a comment